> Am 10.06.2025 um 23:13 schrieb tom ehlert via Freedos-devel > <freedos-devel@lists.sourceforge.net>: > > Not FD CHKDSK? For a reason? FAT32?
The reason is that it was already on my disk and is WAY faster than CHKDSK. But FD CHKDSK reports equivalent errors. Setting BUFFERS=1 has no effect on the bug. I also checked with the previous FreeDOS release 1.3. Same bug... I then built a LFN API enabled XCOPY [1]; by adding -D__WATCOM_LFN__ to the compiler invocation, and adding missing findclose() calls needed to free the search handles. While XCOPYing is also PAINFULLY slow as soon as DOSLFN is loaded, this does not seem to reproduce the file system corruptions when copying the ARACHNE directory on an uncorrupted file system. No idea why DOSLFN is so painfully slow. It is also slow under the EDR kernel. Have not checked MS-DOS though. This should be further investigated, especially if there are file system corruptions not involving FDNPKG. But it won't be me. In the meantime, I recommend that we add this to a "known issues" document and publish this on the Website, so that people are informed of the issue. At least the data corruption bugs should be clearly communicated on the website. [1]: https://nextcloud.iww.rwth-aachen.de/index.php/s/fxwLtD6fcdZNzbt _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
