Moving symbolic links on SFS partition??

[alfkil]

Is it possible to move symbolic links on an SFS partition? If yes then how? If not then why?

[nbache]

Hmm, good question .

Something is definitely weird about that.

If, on an SFS\0 volume, I create a file (using C:Echo) and a soft link (using C:MakeLink) to that file, and then move the soft link to another directory on the same disk (using C:Move), it moves the targeted file, not the link! So I end up having an unresolved link in one directory and a file in the other, both with the same name, the one the link had!

Best regards,

Niels

[alfkil]

And even worse: When trying to do it (move the file) with mv, it just fails. And Filer too. This is very annoying, since Qt wants to use this functionality to move libraries and links (version extended) to libraries into the right directory.

[nbache]

And even worse: When trying to do it (move the file) with mv, it just fails. And Filer too. This is very annoying, since Qt wants to use this functionality to move libraries and links (version extended) to libraries into the right directory.

Okay, if you used mv, you probably also used ln, not makelink. It may make a difference, I'm not sure they create their links in the same way.

Either way, something's not right, though. I don't know enough about SFS or ln/mv etc. to be sure what is wrong and what is more wrong (or whatever ).

Hopefully someone with more insight will chime in.

Best regards,

Niels

[tonyw]

It does exactly the same on RAM, FFS and JXFS, so it doesn't look like an isolated case.

A soft link (just like a hard link) acts as a handle to a target (file or directory). The only difference between a soft link and a hard link is that the soft link is an absolute path and the hard link is relative. Whenever you use the link name in a command, you are referring to the target of the link (the file), not the link itself.

What are you trying to do?
1. Change the content of the link so that it points somewhere else? In that case, you must delete the old link and create a new one that points to the desired place. If you just say "move" (or "mv" or "rename"), you are going to move the target, not the link.
2. Move the target file or directory? That is what is happening here. When you say "Move/mv/rename <linkname> <destination>", you are moving the target to the destination. The link itself does not move, so, since the file/dir has moved, the link is now unresolved.

Remember that a soft link is no more than a file, whose text content is the absolute path of the target.

For example, use the volume "Test:"
>echo >file01 "Hello, world!"
>makelink soft link01 file01
>

Now the soft link "link01" contains the text "Test:file01". You can't type it out, because it does not behave like a file, but that's what it holds.

>makedir dir01
>move link01 dir01/
>

You have moved the target of the link "link01" into directory dir01/ [Here I would have expected the file to be called "dir01/file01", but that's another question].
Since the link itself ("link01") still says "Test:file01", it can't be resolved, because there is no such file.

[colinw]

Is it possible to move symbolic links on an SFS partition? If yes then how? If not then why?

Because softlinks are references to other objects on the same volume or on others.
For dospacket based filesystems, softlink targets are generally relative to the links directory,
if you were to be able to move the link, the target would no longer have a valid relative reference.

On the newer filesystems, softlink targets are always stored as an absolute path reference to an
object on the same volume or others, it wouldn't be troubled by being moved, the absolute reference
would still be valid.

However, an operation on a link is always equivalent to performing the operation on the target object,
so softlinks cannot be treated as discreet objects like files or dirs and renamed,moved,etc...

[alfkil]

So the problem is absolute versus relative linkage? That makes sense, because it used to work on my FFS partitions on my sam,

The thing that Qt does is this:

1) create a shared object (for instance libQtCore.so.4.7.0)
2) create links to this object (ie. libQtCore.so.4.7, libQtCore.so.4 and libQtCore.so, all pointing at libQtCore.so.4.7.0)
3) move all four files to /qt/lib

What you are saying (or how I understand it) is, that the reason this works on FFS is, that all the links are relative, so when moving both the links and the "real" file, at the same time, and to the same place, the link will persist because it is relative.

Stupid question: Why has this behavior been changed with the newer filesystems? Since Qt's way of doing things works on all other platforms, this must be a specific AmigaOS thing, and in this specific case it breaks compatibility with qmake. Well, I guess I will have to reinvent the wheel and implement some amiga specific functionality in qmake...

[tonyw]

I don't think it's changed in any filesystem that you have access to. According to my experiments this morning, FFS, JXFS and ram-handler all behave the same way, and that is the same way as you have reported. I didn't check SFS, but those I did check behave the same way as your SFS.

FFS, SFS and JXFS have not been changed in years. Only ram-handler has been changed, and that still mirrors the behaviour of the others.

[chris]

2. Move the target file or directory? That is what is happening here. When you say "Move/mv/rename <linkname> <destination>", you are moving the target to the destination. The link itself does not move, so, since the file/dir has moved, the link is now unresolved.

Hmm, I'd expect move/rename to operate on the link itself rather than the target. What possible use is there for renaming a file via a link, which then presumably means the link will no longer work?

Everything else, sure, but rename should operate on the exact object specified, it shouldn't be resolving the link.

[alfkil]

@tonyw

As colin states, something has indeed changed, namely the way the link makes its reference:

On FFS: possible relative path
On SFS: always absolute path

The reason this is problematic is, that the SFS behavior doesn't mimic the behavior of other operating systems. Qmake works with the same code on macOSX, Cygwin and Linux, and it relies on being able to make a relative link, which is then moved together with the linked file, so the connection is kept. This will not work on SFS.

Also note, that on FFS, when using "mv" instead of "move", the link is copied as a link and not as a file. On SFS "mv" just fails no matter if the link is valid or not.

Annoying as it is, I have changed the qmake behavior to make the links after the file has been copied. I guess there is no point in hoping for a change in the filesystem...