Opened 6 years ago

Last modified 3 months 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


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 Changed 6 years ago by Valery V. Sedletski

Milestone: milestone1
Version: 1.0

comment:2 Changed 4 years ago by diver

Milestone: Future
Severity: highest

comment:3 Changed 4 years ago by Valery V. Sedletski

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?

Last edited 4 years ago by Valery V. Sedletski (previous) (diff)

comment:4 Changed 4 years ago by Valery V. Sedletski

Last edited 4 years ago by Valery V. Sedletski (previous) (diff)

comment:5 Changed 3 years ago by Valery V. Sedletski

Priority: majorFeedback Pending

comment:6 Changed 3 years ago by Valery V. Sedletski

Priority: Feedback Pendingmajor

comment:7 Changed 3 years ago by Valery V. Sedletski

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 Changed 3 months ago by martini

Hi Valery. Do you think it will be good to close this ticket? Or are you still working on it?


comment:9 Changed 3 months ago by martini

Owner: changed from Valery V. Sedletski to Valery V. Sedletski
Status: newassigned
Note: See TracTickets for help on using tickets.