symbolic links?

I’d like to be able to make symbolic links so that I can collect a bunch of files from various directories into one convenient place for CC to beat them up. Sure, I currently have a Makefile that refers to this file over there, that file other in that corner, oh, yes, include files are on this path… etc.

Tidier would be nicer. Links would probably help.

LinkFS, to my amazement after so many years, works ok to link directories but they don’t help me too much. Googling finds ancient references to a small variety of utilities that I can’t track down anymore. Anybody got current links, code, an interest in writing some?

I do not know whether Links on http://www.wra1th.plus.com/throw.html
is any help?

UnixLib supports SymLinks (1C8), but not transparently (ie its a fiddle). A module could transparently support links, but it would be best if it were via a new filetype to avoid weirdness with UnixLib and compatible apps.

An ImageFS wouldn’t work, but sitting on various file vectors would.

Argh! Gavin, your Link is close but the compiler awards no cigar. Dang.

Making a link to the Makefile and d-clicking that works just fine; the build proceeds as normal. Making a link to a C file fails because the compiler simply reads you link file as text and doesn’t want to play. What a pity.

A new FS which supports this sort of thing would be lovely. I know there’s a big bounty related file on this site but links are quite low in the list and I don’t see any news of big progress :-(

I see. So you need a reference to a link to be interpreted as a reference to the link’s target? Is that how soft links in Unix work? That would require a modification of how RISC OS interprets Obeyfiles – you would need lazy rather than eager evaluation of Obeyfile expressions, or something like that.

No, symlinks must be supported at the lowest levels of the file system API, not in one specific use of files (Obey). That’s why I said it would have to sit on various file system vectors. Almost all of them in fact.

Your only option right now would appear to be to have the makefile copy all the various source files into your temporary build directory. Yuck!

Steve, that would be plausible (although as you say a touch yuck) for a simple chunk of C code. The VM for Squeak is not simple. We have the core application, with some code portable across all the platforms that are supported and a number of platform specific files – the C main() , window handling, input event handling, timers, stuff like that. Then we have a variable but quite large number of dynamically loadable modules (I use the very fabulous rink system for this) that again have portable parts and platform specific parts – sockets, large integers, 3D graphics, gesture recognition, locales, sound sample generation etc etc.
To add to the fun, many field are generated fro ma pseudo-C language that runs within the Squeak and lets us create a modified VM design, simulate it with a real Squeak world and then pump out the compilable C code. I’m not going to claim it’s good quality C but it is at least always a known working design by that point.
Links would at least make it nice and easy for me to make each chunk sit tidily in its own little place instead of sometimes three places with the concomitant fun with specifying paths in a makefile.

And they have so many other uses as well. Please Santa, bring me links for this year?

I will have a go at knocking up a symbolic link module.

IIRC, Martin Würthner did a module called “SoftLinks” in the old days (perhaps RISC OS 2?) which worked perfectly. Maybe ask him for the source?

It turns out I’ve already written one, in 2001. Forgot all about it. Checking…

The VM for Squeak is not simple.

Ah, yes. I’ve done some work with that in the recent past. It’s a fairly complicated beast so I feel your pain.

Ah yes Steve, Eben has explained a bit. There will be some interesting problems we need to discuss sometime soon…

Nemo, once you’ve got symbolic links working, how about quickly putting together a real filing system like maybe ZFS? (http://www.freebsd.org/doc/handbook/filesystems-zfs.html) I realise it might be tricky with the rather large memory usage it seems to desire but we’re a clever lot and there are several of us…

Slightly off topic, but is the “File system improvements (Step 1)” bounty going anywhere?

Turns out I wrote ‘SyLink’ already, but didn’t finish it, so it’s buggy.

However, OS_Find/BGet/BPut/GBPB work so it’s pretty usable already, including from the command line (which is the important bit). OS_File is broken though. Didn’t have time to look at it over the weekend.

Design choices, some may be open to negotiation:

• This is for files only. Directories need an ImageFS.
• Sylinks look like the target file, so can’t have different timestamps.
• No protection against deleting or moving the target.
• Sylinks can have different access attributes, so…
• Trying to overwrite a locked target will overwrite the Sylink if it is unlocked.

how about quickly putting together a real filing system like maybe ZFS?

I quote, “At a bare minimum, the total system memory should be at least one gigabyte”. Forgive me if I don’t spend too long on that.

Tim – have you read the ZFS wiki page? Don’t you think that is a bit overkill for a non-server OS?

how about quickly putting together a real filing system like maybe ZFS?

maybe ext2: http://www.freebsd.org/doc/handbook/filesystems-linux.html

I’ve just been copying a large number of files from a Linux system to RISC OS. There are many symlinks in the source, which means it’s impossible to get a reasonably accurate copy.

So I too would like to see symlinks in RISC OS.

So I too would like to see symlinks in RISC OS

Given the contributions above, perhaps someone could prod nemo to open the source to the “buggy” module