Filesize limit on vfat ?

[blueICE]

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]

[Dani]

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

[DMR]

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

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

[Dani]

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

[)BIG"B"Affleck]

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

[DMR]

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.

[TallCool1]

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.

[DMR]

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

:)

[TallCool1]

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.

[DMR]

...besides, I wanted a valid reason to use "" in a message...

lol. :D

[blueICE]

Thanks for the many answers so far !
I just came back from vaccation and was not able to answer any earlier.
It's correct that 32bit-systems use signed ints as position-parameters in fseek() for example, but the versions I use are compiled to use the 64bit replacements fseek64() and so on. So it schould be possible to address the whole 4Gigs in the file. I checked the system-calls of cat and dd and they use the 64bit replacements to handle the file - so I'm wondering why it does not work - as it seems that it's a kernel problem. I could not find any patches for the kernel related to that problem - any suggestions ?
(I can't beleve that nobody else had this problem so far)

Best regards,
Dietmar
[BlueICE]