Re: mdsl source & another metadata question
Re: mdsl source & another metadata question
- Subject: Re: mdsl source & another metadata question
- From: Terry Lambert <email@hidden>
- Date: Tue, 15 Aug 2006 18:18:04 -0700
On Aug 15, 2006, at 5:05 PM, Jeffrey Ellis wrote:
His output looks like Linux output. You can get something simillar
in OSX
using the -x switch, i.e. "stat -x ls" and "stat -xL ls". Note you
still
only see "ls" and never "/bin/ls" in OSX but you are told different
inode
numbers and the file type is "Regular File" and "Symbolic Link" in
the
other.
Best regards,
Anton
$ ln -s /bin/ls .
$ stat ls
234881059 923574 lrwxr-xr-x 1 jeffrey jeffrey 0 7 "Aug 14 13:52:58
2006"
"Aug 14 13:52:58 2006" "Aug 14 13:52:58 2006" 4096 8 0 ls
$ stat -L ls
234881059 612750 -r-xr-xr-x 1 root wheel 0 32460 "Aug 10 14:57:01
2006" "Mar
21 14:49:19 2005" "Jun 26 03:33:30 2006" 4096 64 0 ls
What am I doing wrong?
All My Best,
Jeffrey
You're not doing anything wrong. As you can see, you are the owner of
the symlink whereas root is the owner of the actual binary.
--
Steve Checkoway
Thanks to you both. I think I was actually asking about the more
readable
form of the output.
Apparently the issue here is that, as I read it, the symlink can
have a
different ownership than the original file. Hence the need to
faithfully
reproduce the ownership of the symlink file specifically.
It depends on which FS you are using, and which Mac OS X version you
are running.
If the FS does not support symbolic links as first class FS objects
(i.e. it implements them as immediate files or some other strategy),
then usually the ownership and permissions depend on the directory
where the link is located, and are actually retrieved from there,
rather than the symbolic link itself.
If the FS supports it as a first class FS object, then it depends on
the implementation of the the filesystem for the OS. Prior to Tiger,
symbolic links in HFS were implemented as first class FS objects, but
the ownership and permissions were inherited from the directory node.
This changed in Tiger.
Just to mix things up, the answer is different for HFS and UFS, for
different versions.
This is basically why, even if an OS fully supports the completely non-
standard lchmod() or the POSIX standard lchown(), you have to be
careful to check for error returns of EOPNOTSUPP (it should have been
ENOTSUP, but the original implementation of lchown() made a mistake on
the error code and returned the socket error, which is what got
standardized):
<http://www.opengroup.org/onlinepubs/009695399/functions/lchown.html>
The currently preferred way of dealing with setting this information
on older versions of the OS is to use setattrlist(), but like lchmod()/
lchown(), its support of changing symbolic link attributes will depend
on the FS. Most people find it easier to simply set it to the same
values as the directory/leave it alone, depending on whether or not
the ability to change the ownership and/or set the permissions is
supported by the underlying FS, so that the behaviour is consistent
across all FS's.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden