nexus wrote: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...
MichaelMerkel wrote: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.
MichaelMerkel wrote: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.
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.
MichaelMerkel wrote: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.
MichaelMerkel wrote:
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 wrote:
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:
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?
ChrisH wrote: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.