Moving symbolic links on SFS partition??

[xenic]

@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

Are you positive that is what he is saying? I just tested on an SFS2 partition and was able to make a relative soft link. Here is what I did:
Changed the current directory to a subdirectory on an SFS partition.
Entered "makelink mylink TO myfile SOFT.
Listing the directory shows "mylink" as a relative link to "myfile".
Strangely, listing the link by name (list mylink) doesn't show that it's a link; it shows the comment on the file that it is linked to (i.e. myfile).

If your system partition is SFS, you will probably see relative soft links when you perform "list SOBJS:".
Hard links are always shown as absolute when listed with the "list" command but hard links only work on FFS.

I don't think the problems with moving links with OS4 has anything to do with whether they are relative or absolute. The problem is that programmers who write commands and programs that copy or move files haven't read the OS4 DOS documentation thoroughly. OS4 AmigaDOS resolves links automatically. If you "lock" a link, you are actually getting a lock on the "linked" file and when you perform the copy you will be copying the file; not the link. If you use the DOS "NameFromLock" function on the lock to get the filename to delete for a move, you will get the name of the linked file and not the link. Therefore you will delete the linked file and leave a broken link at the source. If an OS4 program is just moving files without taking the automatic link resolution into account, you will see unusual results. OS3 doesn't have automatic link resolution so you can't port some OS3 DOS code to OS4 without some changes.

If I'm wrong about this, I'm sure Colin will correct me.

[alfkil]

@xenic

I am positive. Try using "Filer" to view your files. In the file comments it will show the complete path to "myfile".

Another irritating problem is caused by the same non-relative paradigm:

1) cd ram:
2) mkdir lib
3) echo >lib/test.txt "hello"
4) mkdir src
5) cd src
6) mkdir lib
7) cd lib
8) makelink //test.link //lib/test.txt SOFT

makelink will complain, that it cannot find "//lib/test.txt". If on the other hand you write...

9) makelink test.link //lib/test.txt SOFT

...there is no problem. If you use "ln -s" instead...

10) ln -s ../../lib/test.txt ../../lib/test.link

...it "works", but you get an invalid link. If you read the link value with Filer, you will see, that "ln" has tried putting "RAM:lib/" in front of the target file path/name (resulting in very ugly "RAM:lib///lib/test.txt"). This is obviously wrong.

I am surprised that noone has been bothered by this nutty behavior before now. Well, maybe because there are not a lot of people porting Qt apps and the likes... Hmm.

[nbache]

@xenic

I am positive. Try using "Filer" to view your files. In the file comments it will show the complete path to "myfile".

Are you sure Filer doesn't just expand a relative path to an absolute for the display?

Best regards,

Niels

[tonyw]

AFAIK SFS and JXFS don't support hard links at all. They save "hard" links as a relative soft link.

The different behaviour that you are seeing with Filer, WB, C:List, etc is due to the way in which those applications interpret and report the contents of links. They do not all behave the same and some are buggy.

The current version of SFS dates from January 2011. All the other FS date from 2009. None of them has been changed recently. The only thing that has changed recently is DOS. New DOS features have been introduced since V53.90 (end of 2011). If you think that some link behaviour has changed, I suggest that you take a copy of DOS from Update 4 (that would be V53.90) and see if that restores what you expect to happen. There isn't anything else but DOS and the filesystems and the filesystems haven't changed. I'm pretty sure that DOS hasn't changed in that respect, either.

[alfkil]

@Niels

Look at the last example I gave (no. 10) with "ln -s"). Filer shows the linked file to be "RAM:lib///lib/test.txt", which would be very illogical, if Filer was constructing the path itself. This, and also the fact, that it shows this information for a link that points nowhere, indicates, that it is showing the actual content of the link. Also, all of the strange behavior, that I have encountered so far only makes sense, if SFS doesn't allow relative links.

@tony

I am not saying, that anything changed in SFS, it probably hasn't, but something has changed from FFS TO SFS, namely the lack of relative linkage.

Pffft... What I am saying is only this: Probably there is not going to be a change in the "absolute path" linkage behavior in SFS, which is of course fine now that I know (although I still can't for the world fathom why this has to be so). BUT it would be very nice, if at least the bug (which is by all definitions "A BUG") that I mentioned in my previous post would be fixed. At the moment, I am wasting my time editing Qt project files and changing the behavior of qmake, time I could have spent fixing REAL bugs in libQtWebKit. And *please remember*, that everything worked perfectly fine under FFS.

[Slayer]

I used to hate softlinks with a passion and used to backup my GG: installation with tar then untar it with the -h operator so it would dump the file instead of the link

Not sure if this indeed is the proper solution but it sure made moving my GG: installation across volumes alot easier

We do have backup now that supports softlinks but I think there is a still some isolated problems with that because some of my backup installations now have unresolved links due to relative paths no doubt

In todays storage age surely we can live with 5 copies of a 100k file OR syntax switches should just be supported

Sorry for the OT ramble

[tonyw]

@alfkil

And *please remember*, that everything worked perfectly fine under FFS.

What "worked" under FFS may or may not work under another FS. All filesystems have their own peculiarities - call them bugs if you like, but then you must define what is "perfect". FFS certainly is not perfect, neither is any other FS. There is also the question of what "ln" does compared with "makelink". They are not the same program and may act quite differently, depending on how much of the work they do themselves, how much they leave to DOS and how much DOS passes over to the FS.

It all depends on what you are used to. There is no specification in AmigaOS4 for the functionality of hard and soft links, only what people are used to, and all FS are different. So are the applications that talk to them and present internal data like link contents to the user.

We are currently in the process of laying down a specification for filesystems, defining what they must do and what they must not do. In order to test the specification, we are experimenting with new filesystems whose behaviour we can vary as we wish. It's proceeding, but it will be a slow process with only two of us working on it.

[xenic]

I am positive. Try using "Filer" to view your files. In the file comments it will show the complete path to "myfile".

You are wrong. The list command and DOpus4 show it as a relative link. FIler is apparently expanding the path as nbache has suggested. I suggest you file a bug report for "Filer".
Try this:
make dir1 and dir2 in ram:
copy a file to dir2 as "testfile".
cd to dir2.
make a relative soft link to testfile with "makelink link1 TO testfile SOFT.
make an absolute soft link to testfile with "makelink link2 TO RAM:dir2/testfile SOFT.
Use "Filer" to move dir2 into dir1.
Look in the moved dir2 at testfile, link1 and link2 with "Filer".
Both links will look like absolute links but only link1 will still be a valid link because it is actually a relative link.

[nbache]

In todays storage age surely we can live with 5 copies of a 100k file OR syntax switches should just be supported

As an old database nerd, I have to object.

Redundancy is the road to Hell, not only in databases, but also in filesystems. The point is not the space wasted, but the update anomalies (DB nerd term ): If you have five copies of something which were supposed to be one and the same, when you then make a change to it (i.e. one of them), most likely you will end up with one updated and four obsolete copies.

Sorry for the OT ramble

Likewise

Best regards,

Niels

[tonyw]

Agreed. It's the same problem in a filesystem. The more redundancy you build in, the more hope you have of detecting and correcting errors, but you also have more chance of inconsistencies.