Changes between Initial Version and Version 1 of Ticket #40, comment 13


Ignore:
Timestamp:
Apr 19, 2017, 8:12:15 AM (8 years ago)
Author:
Valery V. Sedletski

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #40, comment 13

    initial v1  
    11Windows doesn't understand EA's created by fat32.ifs. You can try deleting the orphaned EA files. But strange, in my case if CHKDSK finds lost EA's, it properly writes the EA mark byte, so it becomes not lost. Obviously, there is some problem CHKDSK cannot fix atm, so I need to reproduce it on my machine to fix it. So, atm, I only can suggest try deleting the lost EA files.
    22
    3 /largefiles switch does nothing with CHKDSK and EA's. CHKDSK cannot fix the problem, so it remains dirty. You can also set disk to clean state by running f32stat d: /clean.
     3/largefiles switch does nothing with CHKDSK and EA's. I am using /eas switch on my machine too, and it does not cause any problems. CHKDSK cannot fix the problem, so it remains dirty. You can also set disk to clean state by running f32stat d: /clean.
    44
    55/largefiles does not need neither FS_MPSAFEFLAGS2 nor FS32_ATTRIBUTE because it is a 16-bit IFS and does not export FS32_*. It uses FS_CHGFILEPTRL/FS_NEWSIZEL only. FS32_ATTRIBUTE is needed for 32-bit IFS drivers only. The only 16-bit IFS which supports large files is DUMPFS. I only exported the same *L-functions and added FSA_LARGEFILE bit to FS_ATTRIBUTE. Now 64-bit file size and offset are working, but the problem remained, that FS_CHGFILEPTRL is not called, but FS_CHGFILEPTR is called instead and file pointer is truncated. But I am able to copy in/out files of size up to 4 GB. Probably, FS_CHGFILEPTRL is not called by kernel at all, maybe, I'll need to export FS32_* in the future too (I am already trying to create FS32_READ/FS32_WRITE/etc as 32-bit wrappers for FS_READ/FS_WRITE/etc for 64-bit seek to be working, but this is unfinished).