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 !

Best regards,
Dietmar
[BlueICE]

On a windows machine using FAT32, the file size cannot exceed 2 gigs.

Er, IIRC- the FAT32 filesize limit is 4G minus 1 Byte.

Hmm, why did I think 2 gigs then?? Sorry if I gave false info!

Some of us use the left aswell and some dont :lol:



SuSE All I can say she can get a little....... bird NT kernel bird thats what SuSE thinks, your not the first.

Good Luck

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.

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.

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).

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.

lol.