Member Avatar for 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]

  • 5 Contributors
  • 10 Replies
  • 4K Views
  • 3 Weeks Discussion Span
  • Latest Post Latest Post by blueICE
Member Avatar for Dani

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

Member Avatar for 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.

Member Avatar for Dani

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

Member Avatar for )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

Member Avatar for 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.

Member Avatar for 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.

Member Avatar for 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).

:)

Member Avatar for 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.

Member Avatar for DMR

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

lol. :D

Member Avatar for 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]

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.