Opened 5 years ago

Last modified 3 years ago

#13 new defect

Ability to create and work with files of up to 4 Gb in size

Reported by: valerius Owned by: valerius
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 (7)

comment:1 Changed 5 years ago by valerius

  • Milestone milestone1 deleted
  • Version 1.0 deleted

comment:2 Changed 3 years ago by diver

  • Milestone set to Future
  • Severity set to highest

comment:3 Changed 3 years ago by valerius

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_position. 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?

Version 0, edited 3 years ago by valerius (next)

comment:4 Changed 3 years ago by valerius

Last edited 3 years ago by valerius (previous) (diff)

comment:5 Changed 3 years ago by valerius

  • Priority changed from major to Feedback Pending

comment:6 Changed 3 years ago by valerius

  • Priority changed from Feedback Pending to major

comment:7 Changed 3 years ago by valerius

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

Note: See TracTickets for help on using tickets.