Hyperion Entertainment Message Boards

The soft links in my OS4 SDK are relative. In the past I could drag'n'drop (ASyncWB) the SDK to a backup disk and then drag'n'drop (ASyncWB) the SDK from the backup disk to another partition (or the original partition) at a later date. All the links would be correct and the SDK was the same as originally installed. Now the relative links get converted to absolute links when drag'n'droped to the backup disk and when drag'n'dropeded to another partition or the original partition all the links are broken. This problem also prevents simple drag'n'droped backup of my other partitions that contain relative links. I have also noticed that I can no longer create relative links with the AmigaDOS "makelink" command. The lack of relative links totally screws up the possibility of any accurate drag'n'drop copies of directories that contain links because the links all point back to a file on the original partition.

Why were relative links eliminated??

They were not eliminated at all. We still have both relative ("Hard Links") and absolute ("Soft Links"), although the names always seemed to me to be curiously reversed.

To repeat, a Soft Link is a string, the full path name of the target, eg "Progs:OWB/OWB", and can be referenced from any volume. A Hard Link is a relative path, eg "/OWB/OWB". A Hard Link can only refer to a target on the same volume (the same partition). I think you will find that all the links in the SDK are Soft Links, ie they contain the full path name. You will not be able to see it, because it will always be resolved to the target. Nothing has changed in that respect.

What we do have is a mixture of filesystems, some of which implement only soft links, some others have bugs in their implementations. Is it possible that you have changed your Drag 'n' Drop to a partition with a different filesystem, thus experiencing different behaviour?

There were also other implementation issues to solve, these existed since the beginning, which is why
softlink support was so broken or missing in a lot of software that attempted to deploy it,
it always gave coders a migraine, it is also the primary reason why there is no or little backup software
that can backup softlinks and have them work again once restored from the backup.

Softlinks may still be specified as relative to a path with 'makelink', but the target will become an absolute path
when stored because a relative target path required a relative reference, and the only thing a filesystem stores
is the target path string descriptor, relative targets specifications are insufficient to resolve the target object
in isolation, without additional info, especially since the target can even be on a different volume. All sorts of kludges
were employed to make it mostly work, none of which were totally successful without ramifications and all of them
required some damn awfull and extemely ugly and complicated code.

The second most obvious problem is that it was not possible to move a relative target softlink with Rename()
because the reference would no longer be valid for a relative softlink target string after it moved,
so dospacket based filesystems generally return ERROR_IS_SOFTLINK if a Rename() is attempted on a softlink
out of it's current directory, some prevent Rename() on softlinks altogether.
This is no longer required for vector-port based filesystems and renaming/moving softlinks anywhere
on the same volume is now supported.

Then there's the backward compatibility and interoperability with existing filesystems to consider as well,
I coudn't just break every softlink implementation on existing filesystems, so all of it was able to be handled
by just storing the link target as an absolute path.

@colinw
It would have been nice if relative soft links had been retained for links to files in the same directory but I guess we just have to deal with the change to absolute links. If all soft links are now absolute then ASyncWB should probably be changed to copy the links as files (copy the target files) like AmigaDOS copy because copying absolute links is only a good idea if the links remain valid after copied. Sometimes the links might work on another partition because they point to a file on a mounted partition, but that's pretty much a coincidence. Thanks for the response.

xenic wrote:If all soft links are now absolute then ASyncWB should probably be changed to copy the links as files (copy the target files) like AmigaDOS copy because copying absolute links is only a good idea if the links remain valid after copied.

I think it would be more useful, if ASyncWB is going to be changed in this area, that it was instead changed to evaluate whether the links point to somewhere in the directory tree which is being copied, and if so, amend the links so they are still valid after copying. That way, it would finally be really useful for (fully restorable) backups.

And if that same logic could then find its way into C:Copy, I wouldn't complain at all.

Best regards,

Niels

xenic wrote:@colinw
It would have been nice if relative soft links had been retained for links to files in the same directory
but I guess we just have to deal with the change to absolute links. ...

I considered this, but it would cause yet more levels of complexity in itself,
along with a whole new set of bugs and 'gotchas', many even worse than you would imagine.

For example, if it would use a relative target string when it points to something on
the same volume, you would not be able to rename or move them out of the current directory,
but if they were absolute specifications, you could move or rename them anywhere.
It would not be acceptable to only be able to rename or move some links, with the criteria
depending on some sort of creation methodology or where the target just happened to point.

It is also not possible to have the filesystem "interfere" with the target string data either,
the filesystems must have no concept of other volumes DOS path syntax or delimiter characters,
the data could also be in any possible encoding too, the target data must remain just like
the data stored inside any other file, private and arbitrary.

Also, everyone has the expectation that when you create a link to something, you are creating
a link to THAT specific something and in no circumstances will it magically change.
Imagine if you moved a relative link somewhere else within the directory structure,
and that new location just happened to have a completely different object of the same name,
your expectation of the link being for a specific object now shifts to a completely different
object without you realising it. Some may even call that an unforseen feature.

These are just a few of the permutations that I had to consider.

Also, everyone has the expectation that when you create a link to something, you are creating
a link to THAT specific something and in no circumstances will it magically change.

Wrong, that's only the case for hard links. Soft links don't have a fixed target, they are just strings. It's similar to lock Assigns (hard link, resolved when creating it, fixed target) vs. path Assigns (soft link, resolved when accessing it, target can change).

colinw wrote:These are just a few of the permutations that I had to consider.

Sure, but removing the possibility to use relative soft links still sucks big time and causes more problems than you solved. How about checking if the target is on the same volume and converting it to ":foo/bar" instead of "dhx:foo/bar" if it is? It wouldn't fix all problems with the missing relative soft links, but at least some of them.

joerg wrote: How about checking if the target is on the same volume and converting it to ":foo/bar" instead of "dhx:foo/bar" if it is?
It wouldn't fix all problems with the missing relative soft links, but at least some of them.

I can live with that, it should also allow it to work with existing filesystems, i'll see what I can do.

Sorry for the strange query but back in the day

I'd back up my gg: directory with tar (which supported softlinks) and restored it with -h switch ( --dereference dump instead the files symlinks point to )

which of course removed all the links from within gg: and created the files themselves, I always wondered if this actually created problems I didn't know about?

I never noticed anything with configure scripts or adding new installations

I've also wondered especially in recent years is it really that important to save space by having one copy of a file with different front end implementations (sorry for my
crude interpretation) there must be more too it I always thought but the information never seemed to be around

So in short

1) does converting softlinks into actual files cause problems AND
2) is there more to softlinks than saving space

thank you kindly for answering my very old ponderings

colinw wrote:The second most obvious problem is that it was not possible to move a relative target softlink with Rename()
because the reference would no longer be valid for a relative softlink target string after it moved,
so dospacket based filesystems generally return ERROR_IS_SOFTLINK if a Rename() is attempted on a softlink
out of it's current directory, some prevent Rename() on softlinks altogether.

I hope you aren't referring to SFS, because nothing of that is the reason you can't rename soft links on it. A file system must never check the target of a soft link, it's just a string with contents the filesystem has to ignore. Support for soft links in ACTION_RENAME was simply never implemented in SFS, there is no other reason it doesn't work.