elks
elks copied to clipboard
ghaerr
Link emulation for link-incapable filesystems, e.g. FAT
I propose establishing a file format that allows for a sort of "soft" symlink, much like how Windows LNK shortcuts are just special files that link to another file on disk. It could even use the LNK extension. This would allow small files to be created that reference other files and that are treated like symlinks on non-symlink filesystems, including FAT which is apparently a desired target. This would enable the use of tools like BusyELKS on such filesystems. One disadvantage would be that only ELKS would recognize them as symlinks, so extra tools would be needed to make them outside of ELKS. A FUSE overlay filesystem could easily be written that can do the necessary translation on Linux systems (and possibly macOS as well).
I propose establishing a file format that allows for a sort of "soft" symlink, much like how Windows LNK shortcuts are just special files that link to another file on disk. This would allow small files to be created that reference other files and that are treated like symlinks on non-symlink filesystems, including FAT which is apparently a desired target.
This will have to be thought through a bit to determine whether the soft link should be interpreted by the kernel 'exec' function, or whether it should be interpreted at the shell level. If the file is marked with execute permissions (automatic on FAT), then the kernel will look for an a.out header, which would fail since its not an ELKS executable, and the shell will then try to execute it as a shell script. If the soft link file follows the 'shebang' (#!/bin/interpreter) mechanism as the first line (not sure ELKS shell does yet), then an interpreter could be written that reads the symlink on the following line of the file and executes the linked program instead. Some kernels execute the shebang-specified interpreter directly in exec.
This would enable the use of tools like BusyELKS on such filesystems.
Yes, BusyELKS would/will be a great addition for reducing size for certain use cases. However, there are currently a number of problems with ELKS' current command set, which might be easier done by bringing in some more modern binutils versions of commands. I plan to bring that up after we get this next release out.
It could even use the LNK extension.
Using a shebang-interpreter approach, there wouldn't be any need for a special extension, which would allow the commands to appear exactly like the original executables but of much smaller size.
One disadvantage would be that only ELKS would recognize them as symlinks, so extra tools would be needed to make them outside of ELKS. A FUSE overlay filesystem could easily be written that can do the necessary translation on Linux systems (and possibly macOS as well).
No need for any extra tools in this release - the ELKS image building process now doesn't require any host filesystem support for MINIX or FAT images. Thus, with the LNK files being ASCII and shebang-interpreted, they're just like any other file, and would be easily written to any disk set using the package manager.
The idea would be for them to work just like symlinks and not necessarily just for program execution. A combination of a specific extension and reading whatever "magic" from the start of the file should be enough to allow differentiation from regular files, and if we considered that extension "reserved" for the purpose, the FAT driver could just present any file with that extension as a symlink.
Got it. More work, and non-standard, but doable. I would suggest seeing how much use ELKS FAT images get after this release, then consider adding when knowing FAT is used a lot. There are currently a number of disadvantages to FAT in its current implementation, which I plan on fixing, but not in this release - the biggest of which is the 8.3 filename limitation. For instance, /etc/resolv.conf doesn't work. We renamed /etc/rc.d/rc.sysinit to rc.sys so as allow ELKS FAT images to boot, but there is more discussion needed on these issues.
VFAT is cruddy but is definitely something that should be supported if possible. I'm starting to think that it might be a good idea to look into offloading some kernel parts into "userspace" a la microkernels; it would relieve the 64K segment limitation, if nothing else. I think some sort of rudimentary executable compression wouldn't hurt, either, especially if booting from floppies on real hardware, but now I'm rambling about irrelevant ideas...
@jbruchon: You got a lot of ideas, you might want to sharpen your fingers and start getting some pull requests going yourself LOL :)
Jokes aside, I like your focus on usability improvements, there's lots ELKS needs in this area. I plan on submitting a more in-depth roadmap on that and other focus items for discussion shortly.
VFAT is cruddy but is definitely something that should be supported if possible.
Long filenames are implemented - just not debugged. I've dove deep into it and it seems like everything is there for decoding VFAT directory entries, it's just not working for some reason. This will also likely move to the next release, as there's still 3 reported FAT crash bugs that need to be fixed for this release.
My 2 cents on two of these issues: I believe we touched the app compression issue a while back (#226), and I repeat my warning: 286 and below are sloooow systems. Things that work perfectly well in some emu, may end up being - well, unusable on real iron.
FAT/VFAT & future: I like the @ghaerr's attitude: Let's see how much usage FAT gets.
Let me also add a small blip of positive energy: When I discovered ELKS some years ago, I was looking for a tool to help diagnose and fix old systems with broken or damaged components, in particular < 386 - all on one floppy. ELKS was not that tool then, but the potential was there. ELKS as of this month - at least when the floppy is > 1M - is a highly useable tool, and improving at amazing speed recently. Reason for a big hand of applause. Let's hope it can continue.
--Mellvik
- feb. 2020 kl. 03:45 skrev Gregory Haerr [email protected]:
VFAT is cruddy but is definitely something that should be supported if possible.
Long filenames are implemented - just not debugged. I've dove deep into it and it seems like everything is there for decoding VFAT directory entries, it's just not working for some reason. This will also likely move to the next release, as there's still 3 reported FAT crash bugs that need to be fixed for this release.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
There are two unused bits in the attribute field that could be used to indicate it's a link. There's also the byte after the attribute, where 0 is for long filenames and other values are reserved for future use. Using those would allow you to use the filename normally and not need the .lnk extension. You could store the link target in the file and it doesn't matter what dos or windows thinks about it. It will just be a text file to them. With the system and hidden bits set, dos and windows don't show the file normally, but that's not even necessary. I tested with various dos versions and win98 and nothing complained about having that byte changed. Using just that byte would allow you to use long filenames for the link as well.
@ssieb: one thing I am curious about: do either chkdsk or scandisk complain about the weird unknown attributes? :-)
I recall that DJGPP and Cygwin also have some sort of facilities for faking symbolic links --- using these, or at least recognizing these, might be another option.
Thank you!
Providing MSDOS chkdsk or scandisk doesn't complain about using a reserved FAT attribute bit, I think using this method, but not using the following byte, would be enough to implement this suggestion in the ELKS FAT filesystem driver. The VFAT support (still not actually working yet) would be automatic.
I should have been more specific. When I said nothing complained, that did include chkdsk and scandisk. I suppose using only the attribute bits would work with long filenames as well because all the details are in the short filename entry anyway.
My only problem with using those bits would be that they're not settable without special tools. Any tool on any platform can create a text file with a particular extension and format. ELKS targets embedded and old systems, and I could absolutely see someone with some obscure or ancient hardware setup trying to make ELKS bootable on something by sending the files for an ELKS FAT boot disk over a serial connection to a DOS machine that would have no way of setting those bits. I have done far, far stranger things. The other issue is that a non-ELKS-aware file copy of any kind cannot be relied upon to copy those bits, and then you run into the same category of problem that Commodore users would if they ran the CBM DOS VALIDATE command on a GEOS-formatted floppy disk; namely, it didn't know about the magic GEOS structures and ruined the ability to use the disk's files. I would be hesitant to merge any solution that goes down the "use the reserved bits!" path.
You have to pick your tradeoff. I guess the filesystem driver could remove the .lnk extension to have a normal filename, but either way you have to hope you don't get a real .lnk file on the disk. You could even go with both options. Then at least by renaming it, you could make it work until you have the tools to fix it properly. cygwin creates real .lnk files and djgpp creates stub programs that call the real ones. I wonder how much code it would take to create and parse a minimal .lnk file.
While I'm sure LNK files exist outside of the shortcut files first offered up in Windows 95, I would be fine with treating all LNK files specially. Perhaps a mount option could be used to disable the behavior. Notably, the only time the actual file contents would need to be checked is if the file gets hit by either directory traversal code or an lstat(). Choosing a lesser used extension like ELN to reduce "collisions" is also an option.