This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
airminer's profile picture

ln - Symlinks for everyone!

Started by airminer, 30 March 2013 - 09:45 AM
airminer #1
Posted 30 March 2013 - 10:45 AM
I have noticed a disturbing lack of symlinks in computercraft and on the forums, so I decided to write a Diriver/API/Utility for them.
The dirver also uses an other api I wrote, in preparation for conficts with other filesystem-overriding drivers. I will post both of them here for now.

ln Driver/API/Utility: http://pastebin.com/pdh4KBY1

usages:
ln load –> load the API and Driver
ln unload –> unload the API and Driver
ln help
ln -s <target> [name] –> create symlink [name] pointing at <target>

Note: As of now only symlinks are implemented. I will propably add hardlink support at a later date.

Public API:
ln.isLink(path,[handle])
ln.createLink(target,name)

fsPlugins API: http://pastebin.com/wvWSzcMr

usages:
usages:
fsPlugins load –> load the API and Driver
fsPlugins unload –> unload the API and Driver
fsPlugins help

Public API:
fsPlugins.registerHandler(handler)
fsPlugins.removeHandler(handler)

The problem, that the fsPlugins API solves:
SpoilerLets say, that I have two drivers: a driver, which mounts remote shared folders (like smbfs), and the ln driver. Both of them use the following method of overriding the fs.open method:

-- Save the original value of fs.open
openRaw = fs.open

fs.open = function(name)
  -- Use the stored raw method
  return openRaw(redirectedStuff)
end
Of course, if the fs.open value has already been modified, the driver will use that as the raw value. The problem comes in, when - for example - you have the ln driver loaded first, and you have a link pointing at a smbfs directory. As the smbfs driver doesn't know that the link file points at an smbfs directory, it passes the file on to the ln driver, which - as it doesn't know about the smbfs driver, and passes everything to the raw fs.open - classifies the link as a symlink pointing at a non-existant file.

With the fsPlugins API, if one driver modifies the path, or access method of a file, it is ran through every other driver again, to sort out these kinds of problems.

Full documentation for both APIs are in the source code!
jesusthekiller #2
Posted 30 March 2013 - 11:21 AM
Looks neat! I would make it API-proof by just making files with just "shell.run(SYMLINK-TO)".
airminer #3
Posted 30 March 2013 - 09:50 PM
I started describing the problem that fsPlugins solves, but then I realised, that It may not be a problem after all. I will look into this.
EDIT: See post below
airminer #4
Posted 30 March 2013 - 09:58 PM
Ok, it IS a problem, but I somehow managed to avert it in the ln driver without meaning to :)/>
No, I didn't, let's get back to descibing that problem…

EDIT: Posted explanation in the OP
airminer #5
Posted 30 March 2013 - 10:34 PM
Looks neat! I would make it API-proof by just making files with just "shell.run(SYMLINK-TO)".
Well, you can run the program in the shell, using the arguments: ln -s <target> [name]
without loading the API or the driver.
Note, that the last argument is optional, just like it would be on a *nix machine