Hi, some comments.
First, I find it absolutely remarkable that the combination of FreeDOS kernel and DOSLFN went without reported problems for 20+ years. So much for 'testing' by installing ... >> Am 10.06.2025 um 14:19 schrieb Jerome Shidel via Freedos-devel >> <freedos-devel@lists.sourceforge.net>: >> >> When installing the ADT2 package[1] from the repository at FD.LOD.BZ using >> FDNPKG, it would install the 999 files in the package. However, the >> FREEDOS\PACKAGES\ADT2.LST file would only contain about 300 entries. How is FREEDOS\PACKAGES\ADT2.LST generated? when UNZIPping the package, or later by scanning installed files? >> Uninstalling the package would obviously leave many files behind. There may >> have also been some file system corruption during the install. >> > These are actually file system corruption bugs. Steps to reproduce: > - Install DOSLFN and reboot > - Change to the \packages\net directory of the FreeDOS installation CD or > wherever your FreeDOS packages are > - Install arachne via FDNPKG install arachne.zip Many thanks for this. Making bugs reproducible is usually the first 50% of bug fixing. > Do a MS-SCANDISK on the FreeDOS system drive. Result: corrupted file system. Not FD CHKDSK? For a reason? FAT32? > FDNPKG is a 32 bit executable built with DJGPP. One can prevent the DJGPP > runtime from using LFN functions by setting the environment variable LFN=n. > Package installation is then at least one order of magnitude faster (down > from 23 minutes to 53 seconds), and the file system corruption does not occur. Faster is ok. But 10+ times faster is not. There is something wrong. > File system corruption also does not occur when installing via FDINST install > arachne.zip, as FDINST has no built-in LFN support. > Further, exchanging the FreeDOS kernel with my EDR fork from [1] (and > creating a dconfig.sys resembling fdconfig.sys), then installing the package, > does NOT seem to corrupt the file system. > So the bug only seems to occur when using DOSLFN under the FreeDOS kernel. > Not sure which is to blame. Theoretically it could also be a FDNPKG bug. But > chances are low... I also think the chances that FDNPKG is to blame are low; it would still be useful to recreate the bug using COPY (XCOPY doesn't support LFN). My first guess: DOSLFN probably writes to the disk using INT25/26. (I never looked into it). If there is an attempt to flush DOS buffers cash (because it is now written to by DOSLFN) that works on MS/DRDOS, but is ignored by FreeDOS (or fails) the result might look like this error. Might be interesting to look what interfaces to DOS DOSLFN uses. One quick experiment would be to run the install procedure using BUFFERS=1 and see if the missing files in ADT2.LST vary. Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
