Re: mdsl source & another metadata question
Re: mdsl source & another metadata question
- Subject: Re: mdsl source & another metadata question
- From: Jeffrey Ellis <email@hidden>
- Date: Tue, 15 Aug 2006 21:01:32 -0700
- Thread-topic: mdsl source & another metadata question
on 8/15/06 6:18 PM, Terry Lambert at email@hidden wrote:
> 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
Hi, Terry--
Thank you for the detailed explanation. I guess we'll have to start testing
in the various OS's we support.
All My Best,
Jeffrey
_______________________________________________
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