| 1 | | 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? |
| | 1 | 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? |
