On Mon, 11 Jul 2005 10:32, Nick Rout wrote:
> On Mon, 11 Jul 2005 10:18:18 +1200 (NZST)
>
> John Carter wrote:
> > On Mon, 11 Jul 2005, Steve Holdoway wrote:
> > > On Mon, July 11, 2005 8:30 am, John Carter said:
> > >> The file pointed to doesn't have to exist, or may exist on a different
> > >> drive. The symlink itself is not a file, it is merely a tweak inside a
> > >> directory file.
> > >
> > > Err... a hard link is a duplicate entry to a pre-existing inode entry
> > > on that partition. That said, the file *must* exist before hard linking
> > > to it.
> >
> > Yup, I was talking about symbolic links (symlink) not hard. Destination
> > of hardlink must exist and exist on the same partition. Destination of
> > shambolic link needn't be on same partition, or same drive or even exist.
> >
> > Now that I have spotted my mistake and seen that symlinks have there own
> > inode number. Question for the group:
> >
> > Without writing my own code, how can I open the symlink file (not the
> > file it points to) with something like "od" to see whats inside it?
>
> I think that all that is inside it is text with the path to the file it
> is linked to. If you look at the length of a symlink, it is always the
> same as the number of characters in the path+file it points to.
>
> The system knows that it is a pointer to another file because it's file
> type is "link".
>
> > Fascinating, I can use the command inode-cat to do this to a conventional
> > file, but it freaks with a lseek error if I point it at a symlink inode.

How about something like:
$ echo -e "one\ntwo\nthree\n" > f1  # Make the original file
$ ln -s f1 Soft_Link_to_f1          # Symbolic link to it
$ ln $(stat Soft_Link_to_f1 | grep '^  File:' | cut -d "\`" -f3 | \
   cut -d "'" -f1) Hard_Link_to_f1
$ ls -li
total 1
156634 -rw-r--r--  2 chris users 15 Jul 11 11:00 Hard_Link_to_f1
156635 lrwxrwxrwx  1 chris users  2 Jul 11 11:00 Soft_Link_to_f1 -> f1
156634 -rw-r--r--  2 chris users 15 Jul 11 11:00 f1

OK It's still a line and a half, but perhaps easier to understand.

It begs the question: Is the current behaviour of ln a bug or a feature?

--
CS

Reply via email to