As Eric mentioned, a lot of disk tools would break. But I feel that swapping out the filesystem is overkill. Better to find the underlying software problem and fix that instead.
I'm very curious about what you said that Dark Forces is a crash culprit. That's unexpected. Are you referring to Star Wars: Dark Forces? I have played the demo and full game several times in FreeDOS, and not had a problem. The video I recorded for our YouTube channel last year was running on FreeDOS (every game there is running on FreeDOS, running inside QEMU). https://www.youtube.com/watch?v=YII4QKdjIds Jim On Mon, Jul 13, 2020 at 6:50 PM Michał Dec <[email protected]> wrote: > Hello Eric, > > Depends. If you want to be able to BOOT from ext4, you would > > have to boot a virtual MEMDISK boot floppy from GRUB, then > > load your new driver to open the ext4 partition ;-) > That sounds a lot like using an initramfs in Linux. Am I getting the > right idea? > > I would NOT attempt to make the kernel or disk tools (format, > > chkdsk and similar) directly able to work with ext4. > > Disk tools I can understand, that would require a meta-utility that can > call filesystem-specific tools based on educated guesses and introduce > universal command line arguments. But kernel? Why? The idea is that ext4 > would be a first-class citizen in kernel space just like FAT16 and FAT32 > are. > > > Of course you would be welcome to make DJGPP DOS ports of > > mkfs.ext4 (mke2fs and fsck.ext4 (e2fsck) and so on. > When and if I get DJGPP working, sure. That's a topic for another > thread. So far I could only get Perl going :) > > Software which has trouble understanding network drives will > > have trouble with your driver, too, but I would not worry > > about that too much. You do want your driver to support any > > long file name interfaces, I think. Having access to ext4 > > disks with only 8+3 character file names would be a pain ;-) > > > > Also, you want to build some type of access rights and user > > identities into the driver, to reduce the risk of breaking > > contents. For example the user could have some user and group > > identity which is used in the driver. There could be a command > > to switch to another user and commands for chmod and similar. > > > > This will of course NOT protect against deliberately breaking > > things, because there is no protection against changing your > > identity to the superuser and doing a deltree etc. :-p But it > > would reduce the risk of accidentally damaging files. > > I'm thinking of the following design decisions in that regard: > > - FreeDOS would not mention ACLs, FreeDOS users lived happily ever after > without them and they can live happily ever after while oblivious to > their existence > > - FreeDOS acts as root UID/GID in the context of reading and writing > from the filesystem except, > > - when creating new files and directories on existing ext4 filesystems, > we must respect the corresponding sticky bit of their parent directory > > I think these would be the least invasive should we ever decide to > inspect a Linux installation under FreeDOS and from ACL perspective an > installation of FreeDOS on ext4 would look the same as one from FAT. > These decisions make sense to me since FreeDOS does not feature groups > and users but it should also not break things for others. > > > But you say neither dosfstools (dosfsck) nor FreeDOS tools > > (Do you use FAT16? Or FAT32?) fail to be able to repair the > > damage. Now you have my attention! :-) > > > > Please describe EXACTLY in which way the filesystem contents > > are broken (no attached files please!) and in which way the > > repairs STILL leave some (which?) damage. > > It's FAT32 and at first. Here's what happened in chronological order: > > 1. I start the offending software. > > 2. It hangs and cuts off input devices, so I restart. > > 3. My SoundBlaster drivers (I'm using a Vibra 128) and initialization > script for it are gone. I know this because trying to run the init > script yielded IO errors in one of the files. > > 4. I shutdown FreeDOS and inspect that file on Linux - it does produce > IO errors, it's completely unreadable. > > 5. I dismount and fsck.vfat -fa. > > 6. I try the offending software again. I have to restart because it hangs. > > 7. I get frustrated and repeat step 6, slightly changing the conditions > so it hopefully doesn't hang this time. Ah who am I kidding, of course > it did just that. > > 8. I realize my FreeDOS can't even shutdown itself by this point. The > files required to do this are broken. So I try some tool (can't remember > the name) from FreeDOS to fix this. > > I can't remember by which point, but there were hundreds of numbered > files in the root of my FAT32 filesystem. Probably recovered files, but > the filenames were lost. > > > Your assumption seems to be that BTRFS and EXT4 would somehow > > be immune to data loss at crashes because they are journaling. > Partly correct. You missed the part where I said FAT breaks so hard it > makes BTRFS blush - that filesystem is also bad news for data integrity. > Some design decisions you can't fix with journaling. > > But as your software breaks FAT worse than chkdsk can repair, > > I would not be too sure about that. > > > > Another idea would be to use FDSHIELD to write-protect the > > harddisk. Of course this only makes sense if your application > > which does those data-destroying crashes does not need to > > write anything to disk. > No, sorry. Rayman and Darkforces for DOS need to be able to write > savestates to its installation directory once in a while. By the way, > these are the culprits. The former is a heavy offender and will hold > your data integrity at gunpoint if you don't even attempt to mount an > ISO with the original CD's data track on it. If the perp is unsatisfied, > it will present a "press this key to continue or other key to exit" > screen but also cut off input devices to mock you. Latter hangs not very > often, but quite unpredictably, probably when he gets a bad hair day. > > A modern EASY solution to your problem would be to run your > > broken DOS application in a dosemu2 window from a Linux (or > > experimentally Windows) based directory. When the application > > crashes, no data will be lost, because DOS never had access > > to the low-level filesystem. Dosemu2 lets you run and even > > boot DOS from a "network" style drive which in fact is your > > chosen Linux directory. Do not forget to load the driver which > > dosemu2 provides for this, otherwise writes will be volatile. > > > > You could also use a diskimage and virtual PC (vmware, bochs, > > qemu, similar), possibly in combination with network drives > > (in particular vmware with vmsmount) or similar, which would > > allow you to make some "disks" write-protected. > > > > Between dosemu2 and virtual PC, you can also try dosbox. > > It is popular on Windows and available for Linux as well. > > Well, yes, I can make it work perfectly in DOSBox, but I have a DOS > machine specifically to do DOS things natively :D > > Best regards, > > Michał > > > > > _______________________________________________ > Freedos-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-user >
_______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
