Re: Copying one hard drive to another - links
Alvin Oga [EMAIL PROTECTED] writes: i dont use hardlinks.. ( creates portability problems ) If you have standard Debian software installed, like gzip, then you use hardlinks. [EMAIL PROTECTED]:/# ls -l /bin/*zip* -rwxr-xr-x4 root root46160 Dec 2 1999 /bin/gunzip* -rwxr-xr-x4 root root46160 Dec 2 1999 /bin/gzip* These files have 4 links to them. Maggie:/tmp/test# ln -s ./pinerc023592 x.s Maggie:/tmp/test# ln ./pinerc023592 x.h Maggie:/tmp/test# ls -la total 2 drwxr-xr-x 2 root root 1024 May 14 20:11 ./ drwxrwxrwt 4 root root 1024 May 14 20:08 ../ lrwxrwxrwx 2 root root 24 May 14 20:08 pinerc023592 - /home/alvin/pinerc023592 lrwxrwxrwx 2 root root 24 May 14 20:08 x.h - /home/alvin/pinerc023592 lrwxrwxrwx 1 root root 14 May 14 20:11 x.s - ./pinerc023592 What unix are you using? That x.h sure looks like a soft symlink to me. On my Debian system: [EMAIL PROTECTED]:/tmp/test% touch .pine [EMAIL PROTECTED]:/tmp/test% ln -s ./.pine x.s [EMAIL PROTECTED]:/tmp/test% ln ./.pine x.h [EMAIL PROTECTED]:/tmp/test% ls -la total 8 drwx--2 jdc jdc 4096 May 15 10:04 ./ drwxrwxrwt 23 root root 4096 May 15 10:03 ../ -rw---2 jdc jdc 0 May 15 10:03 .pine -rw---2 jdc jdc 0 May 15 10:03 x.h lrwxrwxrwx1 jdc jdc 7 May 15 10:04 x.s - ./.pine A hardlink isn't symbolic in that the file name of the target isn't stored. Your test shows a softlink. Dan
Re: Copying one hard drive to another - links
hi ya dan congrats you found more differences in ln ... :-) - very interesting differences in ln ( see the next test below ... done same way as yours... - .pine having been local to the dir makes a difference when my .prinrc023592 file was elsewhere - yes the hardlinks for gunzip and gzip is not a issue in that case since its in the same directory/partitions - hardlinks is a problem when it crosses directories and partitions since it keeps the leading / and i did my silly ln tests on a old rh box... Maggie:~ ln --version ln (GNU fileutils) 3.16 thanx alvin -- re-testing for fun - - same as your results !!! - Maggie:/tmp/test# touch .pine Maggie:/tmp/test# ln -s ./.pine x.s Maggie:/tmp/test# ln ./.pine x.h Maggie:/tmp/test# ls -la total 2 drwxr-xr-x 2 root root 1024 May 15 18:44 ./ drwxrwxrwt 4 root root 1024 May 15 18:44 ../ -rw-r--r-- 2 root root0 May 15 18:44 .pine -rw-r--r-- 2 root root0 May 15 18:44 x.h lrwxrwxrwx 1 root root7 May 15 18:44 x.s - ./.pine On 15 May 2001, Dan Christensen wrote: Alvin Oga [EMAIL PROTECTED] writes: i dont use hardlinks.. ( creates portability problems ) If you have standard Debian software installed, like gzip, then you use hardlinks. [EMAIL PROTECTED]:/# ls -l /bin/*zip* -rwxr-xr-x4 root root46160 Dec 2 1999 /bin/gunzip* -rwxr-xr-x4 root root46160 Dec 2 1999 /bin/gzip* These files have 4 links to them. Maggie:/tmp/test# ln -s ./pinerc023592 x.s Maggie:/tmp/test# ln ./pinerc023592 x.h Maggie:/tmp/test# ls -la total 2 drwxr-xr-x 2 root root 1024 May 14 20:11 ./ drwxrwxrwt 4 root root 1024 May 14 20:08 ../ lrwxrwxrwx 2 root root 24 May 14 20:08 pinerc023592 - /home/alvin/pinerc023592 lrwxrwxrwx 2 root root 24 May 14 20:08 x.h - /home/alvin/pinerc023592 lrwxrwxrwx 1 root root 14 May 14 20:11 x.s - ./pinerc023592 What unix are you using? That x.h sure looks like a soft symlink to me. On my Debian system: [EMAIL PROTECTED]:/tmp/test% touch .pine [EMAIL PROTECTED]:/tmp/test% ln -s ./.pine x.s [EMAIL PROTECTED]:/tmp/test% ln ./.pine x.h [EMAIL PROTECTED]:/tmp/test% ls -la total 8 drwx--2 jdc jdc 4096 May 15 10:04 ./ drwxrwxrwt 23 root root 4096 May 15 10:03 ../ -rw---2 jdc jdc 0 May 15 10:03 .pine -rw---2 jdc jdc 0 May 15 10:03 x.h lrwxrwxrwx1 jdc jdc 7 May 15 10:04 x.s - ./.pine A hardlink isn't symbolic in that the file name of the target isn't stored. Your test shows a softlink. Dan
Re: Copying one hard drive to another - links
Alvin Oga [EMAIL PROTECTED] writes: - yes the hardlinks for gunzip and gzip is not a issue in that case since its in the same directory/partitions - hardlinks is a problem when it crosses directories and partitions since it keeps the leading / Hardlinks can't cross partitions. Try it. The gunzip and gzip hardlinks *do* pose a problem if you use tar to unpack an archive and /usr is mounted in a non-standard place. Try it. I think this is a bug in tar. Dan
Re: Copying one hard drive to another - links
hi ya dan no problem with tar no problem with hard links... i just dont use um...if it dont work for me...i remove um and use relative symlinks c ya alvin On 15 May 2001, Dan Christensen wrote: Alvin Oga [EMAIL PROTECTED] writes: - yes the hardlinks for gunzip and gzip is not a issue in that case since its in the same directory/partitions - hardlinks is a problem when it crosses directories and partitions since it keeps the leading / Hardlinks can't cross partitions. Try it. The gunzip and gzip hardlinks *do* pose a problem if you use tar to unpack an archive and /usr is mounted in a non-standard place. Try it. I think this is a bug in tar. Dan
Re: Copying one hard drive to another - links
hi ya dan i think the problem you have w/ hardlinks is more basic, how to create hard links or soft links... not a tar problem # ln -s /home/foo/something.txt /home/bar - never use explicit directories vs # cd /home/bar ; ln -s ../foo/something.txt . - always use relative directories links becomes a problem when you are logging into many machines on the local LAN and need to get access to the files on other servers /home/foo is a common problem and will break if /home/foo is actually /export/home/user/foo on some machines and not others ( dpeends on disks and who was the admin that inherited the old/broken /home stuff /home should be portable across servers and networks /etc/foo.txt, /var/something/foo.txt areanother misconfigured hard or soft links relative links is the preferred methodology ( hard or soft ) and avoids the leading / and allows the portability of the files to be restored or shared in any level of hiercharcy cd /export/home ; tar zxvfp backup.tgz and the symlinks would still work c ya alvin Gnu tar tries to handle the latter, according to the docs. But I've had trouble with unpacking hardlinks with Gnu tar. They seem to be stored in the tar file including the leading /, so they can't be unpacked with /usr mounted as /mnt/usr, say.
Re: Copying one hard drive to another - links
Alvin Oga [EMAIL PROTECTED] writes: i think the problem you have w/ hardlinks is more basic, how to create hard links or soft links... not a tar problem ... relative links is the preferred methodology ( hard or soft ) and avoids the leading / and allows the portability of the files to be restored or shared in any level of hiercharcy I don't think relative links make sense for hard links. My understanding is that in the file system, hard links are stored by referencing the inode. It is only tar that needs to convert this to a textual form for storage in the tar file. By the way, the files I had problems unpacking were standard Debian executables in /usr/bin and /bin. So I maintain that tar can't unpack hard links properly. Test it out yourself if you don't believe me, Alvin! :-) Dan
Re: Copying one hard drive to another - links
hi ya dan i dont use hardlinks.. ( creates portability problems ) have fun alvin -- note that x.h is dereferenced back to /home/alvin/... which i think is bad but... thats a good reason NOT to use hardlinks ( ... just me ... ) -- x.s is what i want... create it relative and keep it relative Maggie:/tmp/test# ln -s ./pinerc023592 x.s Maggie:/tmp/test# ln ./pinerc023592 x.h Maggie:/tmp/test# ls -la total 2 drwxr-xr-x 2 root root 1024 May 14 20:11 ./ drwxrwxrwt 4 root root 1024 May 14 20:08 ../ lrwxrwxrwx 2 root root 24 May 14 20:08 pinerc023592 - /home/alvin/pinerc023592 lrwxrwxrwx 2 root root 24 May 14 20:08 x.h - /home/alvin/pinerc023592 lrwxrwxrwx 1 root root 14 May 14 20:11 x.s - ./pinerc023592 *poof* to /tmp/test On 14 May 2001, Dan Christensen wrote: Alvin Oga [EMAIL PROTECTED] writes: i think the problem you have w/ hardlinks is more basic, how to create hard links or soft links... not a tar problem ... relative links is the preferred methodology ( hard or soft ) and avoids the leading / and allows the portability of the files to be restored or shared in any level of hiercharcy I don't think relative links make sense for hard links. My understanding is that in the file system, hard links are stored by referencing the inode. It is only tar that needs to convert this to a textual form for storage in the tar file. By the way, the files I had problems unpacking were standard Debian executables in /usr/bin and /bin. So I maintain that tar can't unpack hard links properly. Test it out yourself if you don't believe me, Alvin! :-) Dan
