c:copy command and links

[MichaelMerkel]

With 'cp -a <src> <dst>' from SDK does what you want to do, or am I wrong?

thank you so much! that's working perfect. super!
nevertheless should the original copy command be enhanced. expecially because it is faster.

... and one problem with the "cp" command... the "S" flag is not copied. suddenly some scripts did not work. and that was caused by the former "cp"...

one more problem with the "cp" command i found this week...
if you copy soft links from one drive to another one they point to the old location :-/
example:
just copy the complete SOBJS drawer fom SYS: to WHATEVER: using "cp -a SYS:SOBJS WHATEVER:".
now check the target directory. all links point to SYS:SOBJS/...
that's not so good...

regards...
michael

[nbache]

one more problem with the "cp" command i found this week...
if you copy soft links from one drive to another one they point to the old location :-/

Well, isn't that what a soft link is all about? It's a file containing the path and name of another file (or dir). So just copying it - which would be what cp -a does - won't change its contents, i.e. the target of the softlink.

Best regards,

Niels

[MichaelMerkel]

one more problem with the "cp" command i found this week...
if you copy soft links from one drive to another one they point to the old location :-/

Well, isn't that what a soft link is all about? It's a file containing the path and name of another file (or dir). So just copying it - which would be what cp -a does - won't change its contents, i.e. the target of the softlink.

sure - but i expected the softlink to be relative. if i link one file in a dir to another on in the same dir i expect this to be respected.
that's what this thread was all about actually. making a backup of a partition (or complete folder) using the copy command. if the links are not "copied" (relatively) this makes no sense.

regards...
michael

[nexus]

Hi Michael,

what happens if you use 'mv <src> <dst>' to move a directory to a different partition? Are the links correctly set then?
If so, a workaround would be to 'cp -a' first the directory on the same partition and then, to move it to its final destination.

When you use 'cp -a', do you use Amiga style path names or unix like?
Could you try to use unix style pathnames, maybe with 'abc' shell?

I'd be interested if something of the above works or all fails
Unfortunately, I can't currently test it for my self.

regards,
nexus

P.S @nbache: since 'cp' is a port of a unix command, it should work in the same way as on unix. So, Michael is right. If soft links are set by using a relative path, it should still be relative after copying everything to a different location.

[xenic]

I think the focus of this topic should be getting "copy" fixed. The link problem in the "copy" command was reported long ago and remains broken. We're always encouraged to "backup" before installation but a backup is incomplete if you follow the instructions in the documentation and "copy" your WorkBench to another partition. Either the documentation should be updated to exclude the link treatment or the "copy" command fixed.

Isn't it also about time that we made SOFT links the default for the makelink command? Hard links don't even work on some filesystems that are now included in the OS. Few if any even use FFS anymore and yet hard links are still the default. It might also be nice to achieve some consistancy in the way the current filesystems treat SOFT links. For example, if you have a SOFT directory link from a write protected disk to a disk that is not write protected FFS will write data to the linked directory but SFS will report that the volume is write-protected because the link is on a write-protected disk.

[nbache]

sure - but i expected the softlink to be relative. if i link one file in a dir to another on in the same dir i expect this to be respected.
that's what this thread was all about actually. making a backup of a partition (or complete folder) using the copy command. if the links are not "copied" (relatively) this makes no sense.

Ah, right. I forgot about relative links.

Best regards,

Niels

[xenic]

sure - but i expected the softlink to be relative. if i link one file in a dir to another on in the same dir i expect this to be respected.
that's what this thread was all about actually. making a backup of a partition (or complete folder) using the copy command. if the links are not "copied" (relatively) this makes no sense.
regards...
michael

SoftLink just means that files can be linked to other volumes. A file on DH0: can be linked to a file on DH2: etc. HardLinks can only point to files on the same volume. Links can be absolute or relative. That is determined at the time of creation. For example, libpng.so could be linked to libpng12.so for a relative link instead of using an absolute path (SYS:sobjs/libpng12.so) resulting in an absolute link. If you change the links in SObjs to relative links then they will be copied (at least by WorkBench) as relative.

EDIT: "makelink libpng.so TO libpng12.so SOFT" creates a relative link.

[MichaelMerkel]

sure - but i expected the softlink to be relative. if i link one file in a dir to another on in the same dir i expect this to be respected.
that's what this thread was all about actually. making a backup of a partition (or complete folder) using the copy command. if the links are not "copied" (relatively) this makes no sense.
regards...
michael

SoftLink just means that files can be linked to other volumes. A file on DH0: can be linked to a file on DH2: etc. HardLinks can only point to files on the same volume. Links can be absolute or relative. That is determined at the time of creation. For example, libpng.so could be linked to libpng12.so for a relative link instead of using an absolute path (SYS:sobjs/libpng12.so) resulting in an absolute link. If you change the links in SObjs to relative links then they will be copied (at least by WorkBench) as relative.

EDIT: "makelink libpng.so TO libpng12.so SOFT" creates a relative link.

sure. all the sobjs: links should be relative. still they are not copied by the copy command and copied "wrong" fom cp.
what is now also strange - if you use the LIST command in sobjs: it looks like that:

Code: Select all

.Workbench:SObjs> list
libz.so.1.2                  146639 ----rwed 13-Jul-11  21:01:10
> libz.so.1.2.5
libz.so.1                    146639 ----rwed 13-Jul-11  21:01:07
> libz.so.1.2.5
libz.so                      146639 ----rwed 13-Jul-11  21:01:02
> libz.so.1.2.5
libpng14.so.14               665601 ----rwed 13-Jul-11  21:00:38
> libpng12.so
libpng.so                    665601 ----rwed 13-Jul-11  21:00:18
> libpng12.so

the links really look relative.

if you use the LS command from the sdk (ls -l) it looks like this:

Code: Select all

-rwx------  1 root wheel 4728163 2009-09-09 12:53 libxml2.so
-rwx------  1 root wheel 4750549 2010-11-12 21:14 libxml2.so.9
-rwx------  1 root wheel  277220 2008-09-09 13:34 libxslt-1.1.so
-rwx------  1 root wheel  982601 2009-09-09 13:04 libxslt.so
lr-xr-xr-x  1 root wheel      13 2011-09-25 09:57 libz.so -> /Workbench/SObjs/libz.so.1.2.5
lr-xr-xr-x  1 root wheel      13 2011-09-25 09:57 libz.so.1 -> /Workbench/SObjs/libz.so.1.2.5
lr-xr-xr-x  1 root wheel      13 2011-09-25 09:57 libz.so.1.2 -> /Workbench/SObjs/libz.so.1.2.5
-rwx------  1 root wheel  146639 2010-10-01 12:35 libz.so.1.2.5

this *looks* like absolute... as the volume is part of the link name.

regards...
michael

[ChrisH]

This may not help, but I ran into some really strange behaviour (at least with SFS) when trying to make my own program copy a soft link with a relative path. IIRC the created path ended-up being absolute (but pointing to the wrong place - i.e. it did not use the containing folder as the base for the relative path). In the end I simply had to create a soft link with an absolute path. I wonder if the author of your copy command ran into the same problem, and so used the same work-around?

[xenic]

This may not help, but I ran into some really strange behaviour (at least with SFS) when trying to make my own program copy a soft link with a relative path. IIRC the created path ended-up being absolute (but pointing to the wrong place - i.e. it did not use the containing folder as the base for the relative path). In the end I simply had to create a soft link with an absolute path. I wonder if the author of your copy command ran into the same problem, and so used the same work-around?

I created 2 SOFT links in a directory on an SFS partition; one was relative and the other absolute. When I copied the directory to another SFS partition using WorkBench drag'n'drop the links were copied correctly. The absolute link points back to the file in the source directory and the relative link points to the copied file in the destination directory. To me, that suggests that you did something wrong or didn't use the correct technique to create your copied links. I haven't tried creating links from a program so I don't know how it should be done.