I've recently tried to create an image from a DVD under Linux.
I wrote the image file to an vfat (fat32) partition previously mounted. The copying process stopped by about 2GB, the former file-size-limit of Linux. I've checked my binaries (dd and cat) they both support large files, and they work well on ext2-filesystems creating files larger than 2GB. I looked into kernel-documentation of vfat-filesystem drivers and the struct there says that the file-size is represented by 4 bytes (32bit integer). So the file-size-limit should be (if I'm correct) at 4GB (or 2^32) since it does not make any sens to use a signed integer to represent the file-size (it can't be negative )
So has anybody a clue what the problem could be, please ?
I', using kernel 2.4.18 from SuSE (compiled from source with all large-file-support enabled). (btw. the original Suse 8.0 Kernel does have the same problem)
I would be really glad if someone could help me!
thanks !
So the file-size-limit should be (if I'm correct) at 4GB (or 2^32) since it does not make any sens to use a signed integer to represent the file-size (it can't be negative )[BlueICE]
Actually, you might have found the problem right there. Although I haven't been able to nail down exactly where this occurs (I'd assume somewhere in the vfat implementation, but I can't be sure), I've seen allusions to the fact that that filesize is represented as a signed int. If so, on 32-bit architecture, that would yield a max filesize of 2^31; in other words- 2GB.
I don't know if this relates to our issue here, but when troubleshooting massive filesytem corruption on Macs (HFS/HFS+ filesystems), I've actually seen files report their sizes as negative numbers.
On a windows machine using FAT32, the file size cannot exceed 2 gigs.
Despite DMR's reply, eveything that I have ever read agrees with your 2 GB file-size limit. My reading on this indicates that there's a 4 GB range, but it's signed (for +/- seeking within a file), so the limit is 1/2 the range, hence 2 GB total.
My reading on this indicates that there's a 4 GB range, but it's signed (for ± seeking within a file), so the limit is 1/2 the range, hence 2 GB total.
As I said, after trying to weed out the conflicting information on max vfat/FAT32 filesizes, I'm tending to agree- because the int appears to be signed, that means a 2G filesize limit on a 32-bit platform.
Could you elaborate on your explanation of "for ± seeking within a file" as it relates to the need for the filesize to be signed? (I'm not a programmer by any means, so I'd appreciate the illumination).
Could you elaborate on your explanation of "for +/- seeking within a file" as it relates to the need for the filesize to be signed? (I'm not a programmer by any means, so I'd appreciate the illumination).
I'm not a programmer, either, but here's how I understand it: a negative offset/signed integer range allows you to index forward or backward from an arbitrary position within a file, hence the need.
No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.
Previous Thread in Linux Kernel and Hardware Setup Forum Timeline:wireless net cards
Next Thread in Linux Kernel and Hardware Setup Forum Timeline:Hard drive