Moving symbolic links on SFS partition??

[alfkil]

@xenic

Hmm, I can see that. But how do you then explain the example I gave? And why is it impossible to move a link in any other way than moving its parent directory? Such behavior I can only interpret as "lack of functionality", because nothing is gained by removing this feature. Or is it?

[colinw]

As I mentioned before, it is not possible to move a softlink out of the parent directory for dospacket based filesystems,
the methods used to make them work in the first place are not entirely consistent, in fact most filesystems have to
deploy a certain level of "black magic" to make them work at all, also, some filesystems do allow the links to be renamed,
but not moved, others do not allow any other operations other than creating and deleting them.

I can't change the behaviour for existing dospacket based filesystems, the only thing I can do is to ammend the documentation
for these, to indicate that supporting filesystems will be required to also allow the renaming of softlinks, as long as it doesn't
move them out of the existing parent directory.

For the new style filesystems, it's a different story, because these are made to always store the softlink target string as an
absolute DOS path specification, it doesn't matter what it's called or where it is moved, the target will always stay valid.

That's the best I can do at this stage.

[xenic]

@xenic
Hmm, I can see that. But how do you then explain the example I gave? And why is it impossible to move a link in any other way than moving its parent directory? Such behavior I can only interpret as "lack of functionality", because nothing is gained by removing this feature. Or is it?

Moving the parent directory in the case I presented really resulted in a "rename" of the directory within the same partition, which works on some filesystems as Collin points out. There isn't really a copy() function in AmigaDOS; a program opens a sourcefile and reads data, then creates the destination file and writes the data. It's up to the program how links are handled. The program can use the AmigaDOS automatic link resolution and copy a link like any other file (like Dopus4 & C:Copy) which results in a "real" file in the destination instead of the link. The program can attempt to reproduce the link in the destination but there is no concensus as to how that should be done. Should the link point back to the original file or to the copy of the file in the destination? In the case of a partition backup that you might want to restore, having links reproduced to point to the copied file in the destination would seem to make sense. When you restore your partition the links would be the same as on the backed-up partition. However, if you just want to copy the link to another location on your system you might want both links (original & copied) to point to the same file. A program would need a whole set of prefs or command-line arguments specifying how to handle links. Different programs (AsyncWB, C:Copy, Dopus4, Diskmaster, Filer etc.) handle links differently and different filesystems handle them differently. I just avoid links now.

[ssolie]

...I just avoid links now.

You are wise. As Colin explained, they are implemented differently on each file system. As such, bugs are likely to exist (statistically speaking) in different ways on each file system.

This is also the case with DOS notifications and record locking features. That is, until Colin lifted them out of the file systems and into dos.library itself. The autodocs explain exactly when this occurred. I am also updating the wiki right now to try and document the situation but the docs are not complete yet.

Such features should never have been the responsibility of each file system in the first place. This has made it extremely difficult to correctly implement such features in any Amiga file system. It also has duplicated code again and again. I think we should all thank Colin for his tireless work to finally fix the situation at the root.

[saimo]

Let me add some more feedback - having upgraded to Update 6 just a couple of days ago, one of the things I immediately noticed is that softlinks don't fully work anymore.

Basic information:
* I'm talking about softlinks only;
* I have always used absolute-path softlinks without problems before;
* the only changes in my system have been those brought by Update 6;
* filesystems in use: SFS0 only.

This screenshot illustrates a sequence of operations that exposes an incorrect behaviour:


Steps:
1. I put the picture Angst.png in the data: partition;
2. I made the softlink A to it (accessing the picture through the link works just fine);
3. I tried to made a copy of the link to RAM:, using the COPYLINKS options;
4. The file itself got copied to RAM: (i.e. the COPYLINKS option got ignored);
5. I deleted the file from RAM:;
6. I copied the link via Workbench;
7. the link got copied (it appears in the Workbench window and in the List output), but it does not work (this is because the path is relative).

Notes:
* with links to directories, the behaviour is the same;
* when the link is copied, it does not appear immediately, but a window refresh is required (if the window was already open, that is);
* copying the link via Workbench to any other partition gives the same result;
* moving the link via Workbench to the same partition produces no result;
* the command Move has a COPYLINK option, but it gets ignored just the same;
* the name of the file is totally unintentional: I just picked a random file from a C64 pictures directory and only now I realized that it might lend itself to a negative interpretation.

EDIT

By using an absolute path (i.e. data:Angst.png):
* the link can be copied anywhere via Workbench;
* the link gives access to the target from any location it is copied to;
* the COPYLINKS option still is ignored.

In all, some of the problems reported are simply a consequence of the relativeness of the path, which becomes broken if the link is put elsewhere.
For convenience, I have amended some of the information above and added the summary of the findings below.

ANY LINK
* can be copied elsewhere via Workbench [GOOD];
* can not be moved to the same partition via Workbench [BAD];
* the COPYLINK option of Copy and Move is ignored [BAD].

ABSOLUTE LINKS
* can be copied to and used from elsewhere without problems [GOOD].

RELATIVE LINKS
* the Workbench window they are copied to requires a refresh to show them (this is because they become broken) [BAD].

BROKEN LINKS
* cause ContextMenu to crash (but probably this is not a issue with the links themselves) [BAD].

[nbache]

From the output of "Help copy":

Code: Select all

	COPYLINKS

	    Copy the contents of a file referenced by a hard or soft link;
	    the default is to skip copying linked files.

	FOLLOWLINKS

	    When used with the ALL option, the COPY command will follow hard
	    and soft links to directories; the default is to skip links to
	    directories.

Seems to be working as designed?

Best regards,

Niels

[saimo]

From the output of "Help copy":

Code: Select all

	COPYLINKS

	    Copy the contents of a file referenced by a hard or soft link;
	    the default is to skip copying linked files.

	FOLLOWLINKS

	    When used with the ALL option, the COPY command will follow hard
	    and soft links to directories; the default is to skip links to
	    directories.

Seems to be working as designed?

You're right. At some point in the past, the meaning of those options changed in my mind. My mistake.

However, "the default is to skip copying linked files" does indicate another kind misbehaviour: Copy simply copies the target file even when COPYLINKS is not specified, whereas it should have copied just the link or, according to a more strict* interpretation, nothing at all (I made tests with and without the CLONE option).

*but hopefully wrong, otherwise there is no shell/script-driven way to copy links.

[tonyw]

*but hopefully wrong, otherwise there is no shell/script-driven way to copy links.

Perhaps you should add "...on an SFS/0 volume".

It might be different on SFS/2 or JXFS. It is certainly different on FFS. Also, what C:List tells you is different from what the Workbench window tells you.

The point we are all trying to make is that every C:command and every (old) filesystem has its own interpretation. Up until recently there has been no standard, no specification that is "right".

As we continue to tidy up the system into a more consistent syntax and set of semantics, the behaviour of some old products will change, sometimes in unpredictable ways.

[saimo]

*but hopefully wrong, otherwise there is no shell/script-driven way to copy links.

Perhaps you should add "...on an SFS/0 volume".

It might be different on SFS/2 or JXFS. It is certainly different on FFS. Also, what C:List tells you is different from what the Workbench window tells you.

The point we are all trying to make is that every C:command and every (old) filesystem has its own interpretation. Up until recently there has been no standard, no specification that is "right".

As we continue to tidy up the system into a more consistent syntax and set of semantics, the behaviour of some old products will change, sometimes in unpredictable ways.

I fully understand that the past mess is not easy to deal with and I completely agree with a thorough operation of cleanup and standardization.
That said, the point I was trying to make cannot be dismissed in the light of such considerations. Let me go back to it, expanding the reasoning.

0. One premise was that the whole discussion was (and still is) exclusively about softlinks, the reason being that softlinks, as files pointing to other objects, are instrinsically trivial to handle as regular files by any filesystem.
Hardlinks are totally different beasts and cannot be ignored (unless a decision is made to drop the support for them, but that's another story), of course, but since they are different also at user level (the key distinction being that the referenced objects must reside on the same partition), nothing forbids defining a different behavioural standard for them (it's a given that trying to keep the behaviour as close to that of softlinks as possible is preferrable).

1. The Copy command does not work as documented. One might argue that - as I have observed myself - the documentation isn't obvious to interpretate*, but one thing is sure: the fact that whether the COPYLINK option is specified or not makes no difference indicates that there's a problem somewhere and no change whatsoever should leave the system in such a state.
*Although the meaning is still rather clear: the words indicate that what gets skipped is the linked files, not the links themselves; on top of that, the spirit is just as clear.

2. The reason of the failure is not in SFS0 or OFS (the filesystems I tested), given that Workbench proves that the operation of copying links is possible.
Generally speaking, in the worst case all that's needed is the possibility of retrieving the link path from the source filesystem (which should be a core functionality offered by the filesystem) and of creating links in the destination filesystem (which is obviously a prerequisite): with these basic functionalities, offered for sure by any filesystem that allows linking, it's possible to re-create the links to simulate copies. Moving only requires an additional functionatilty that for sure is offered by a filesystem that supports linking, i.e. the possibility of deleting links.

3. The existence of the COPYLINK option indicates that, design-wise, AmigaOS contemplates the possibility of distinguishing, at user/DOS level, between links and pointed objects. Even if how such distinction is done is not properly documented, still it is desirable to preserve it (a system that doesn't offer that sort of control over links is impaired and the usefulness of links is impaired as well) and standardized logically (preserving compatibility as much as possible).

4. There's no reason why Workbench should be unable/unwilling to move links to another location on the same partition.

5. No program should crash due to a broken link (accessing a broken link as a regular file/directory should be just the same as opening an unexisting file/directory).

Note: the reason why I'm discussing all of this is simply that filesystems and DOS are core aspects of the system, which deal with the most precious resources a user has, i.e. his files. Regarding these matters, no flaw should remain unexposed, no design decision should be taken lightheartedly.