Opened 10 years ago
Last modified 5 years ago
#13 assigned defect
Ability to create and work with files of up to 4 Gb in size
Reported by: | Valery V. Sedletski | Owned by: | Valery V. Sedletski |
---|---|---|---|
Priority: | major | Milestone: | Future |
Component: | IFS | Version: | |
Severity: | highest | Keywords: | size, limit, signed |
Cc: |
Description
Some parts of fat32 sources contain size as a 32-bit signed variable, others contain size unsigned. The limit of unsigned ones is 4 Gb, and signed ones are limited by 2 Gb. Need to unify all variables in sources to be unsigned long.
Change History (9)
comment:1 by , 10 years ago
Milestone: | milestone1 |
---|---|
Version: | 1.0 |
comment:2 by , 8 years ago
Milestone: | → Future |
---|---|
Severity: | → highest |
comment:4 by , 8 years ago
The test version with support of files up to 4 GBis uploaded: ftp://osfree.org/upload/fat32/fat32-0.10.a8-r174.zip | ftp://osfree.org/upload/fat32/fat32-0.10.a8-r174.wpi
comment:5 by , 8 years ago
Priority: | major → Feedback Pending |
---|
comment:6 by , 8 years ago
Priority: | Feedback Pending → major |
---|
comment:7 by , 8 years ago
Now it mostly works, except for a 64-bit seek (FS_CHGFILEPTR is called instead of FS_CHGFILEPTRL, so file pointer is truncated to 32 bits). But copying the big files in/out should work. (sequential file access works, but random one still doesn't).
comment:8 by , 5 years ago
Hi Valery. Do you think it will be good to close this ticket? Or are you still working on it?
Regards
comment:9 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Now I'm trying to make fat32.ifs understand files > 2gb in size. It looks that 2 gb is a limitation of FS_CHGFILEPTR, as it has a signed 32-bit variable for byte offset. The file size field in directrory entries is a 32-bit unsigned, so it can be 4 GB max size, which is supported in WinXP, but not in 16-bit OS/2 IFS-es. The cluster chain length, theoretically, could be unlimited, so it is only limited with a file size field length. I looked inside dumpfs.ifs, as it's the single 16-bit IFS with large files support. It appears, that it has all usual entry points a 16-bit IFS should have, plus two additional ones, FS_CHGFILEPTRL and FS_NEWSIZEL. They are like FS_CHGFILEPTR and FS_NEWSIZE, but with a "long long" and "unsigned long long" offset/size arguments, respectively. So, I added these entry points, instead of their counterparts without the "L" suffix. And made these a wrappers around corresponding "L" functions. Also, I needed to add the FSA_LARGEFILE == 0x20 bit to FS_ATTRIBUTE. And, also, I needed to add the FIL_STANDARDL, FIL_QUERYEASIZEL, FIL_QUERYEASFROMLISTL options to FS_FILEINFO, FS_PATHINFO, FS_FINDFIRST, and FS_FINDNEXT. Additionally, I needed to add the sfi_positionl and sfi_sizel 64-bit fields to "struct sffsi" and change all code to use them, instead of sfi_position and sfi_size. So far, I was able to copy a 3 GB .zip file to a fat32 partition. FC/2 successfully displays the file size and big file copying works. It involves a sequential read/write by FS_READ/FS_WRITE only. Also, I can open a 3 GB file and view its contents in a viewer, but cannot enter the big zip archive. Small .zip archives are entered successfully. According to the fat32 log, the kernel calls FS_CHGFILEPTR on big files, instead of FS_CHGFILEPTRL. Maybe, someone has any ideas, why it is? There is a FSA_LARGEFILE bit set in FS_ATTRIBUTE, which causes to call FS_FILEINFO and FS_FIND* with level == FIL_STANDARDL, and this works, but for DosSetFilePtrL, no FS_CHGFILEPTRL is called, for some reason. What could I miss?