Re: ls -L [some symbolic linked file] not working
Re: ls -L [some symbolic linked file] not working
- Subject: Re: ls -L [some symbolic linked file] not working
- From: Steve Checkoway <email@hidden>
- Date: Wed, 20 Sep 2006 03:51:33 -0700
On Sep 20, 2006, at 12:48 AM, Pelle Johansson wrote:
Justin C. Walker wrote:
The idea is that you can refer to the collection of bytes that
works out to "hello world\n" by the name 'foop' and I can refer to
it as 'goop', and we really don't know that those two different
names are the same file (unless we do some detective work (using
'ls')).
If you type "ls -lL foop", you get the information about the file;
the name remains the same because that is how you refer to it.
I'd suggest everyone who thinks this is confusing read the stat(2)
manpage and consider that without -L lstat is used, but with it
stat is.
I'm well aware of how files and links work and I know the difference
between lstat and stat. My objection was to the man page. I think the
gnu man page more accurately captures the distinction. After all,
passing -L to ls does nothing without -l. After all, what does it
mean to "list" a file if not to display the name? The -l option is
for listing in the long format.
On Sep 19, 2006, at 8:18 PM, Justin C. Walker wrote:
- the difference between a symbolic and a hard link is mostly in
implementation (the former gets you cross-device linking, and can
"break"; the latter is confined to one device and won't break).
I disagree. While both of those properties of links are true, I
wouldn't say that's the difference. As I'm sure you well know, a hard
link is just another link to the same inode with a different path. I
know that either HFS or OS X (I'm not sure which) has issues with
files that have at any point been hard linked whereas a symbolic link
is a different file which points to a path (as can be read by readlink
(2)). There is no difference between an original link to a file and a
hard link to the file. For all intents and purposes, they are the
same file. This is not true of a symlink.
To quote from symlink(7), "A hard link to a file is indistinguishable
from the original file because it is a reference to the object
underlying the original file name." "A symbolic link contains the
name of the file to which it is linked, i.e. it is a pointer to
another name, and not to an underlying object."
--
Steve Checkoway
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden