Re: Setting st_flags returned by stat
Re: Setting st_flags returned by stat
- Subject: Re: Setting st_flags returned by stat
- From: Terry Lambert <email@hidden>
- Date: Sat, 2 May 2009 17:56:24 -0700
The reason you can't look at the link itself is that there are no APIs
that internally set O_NOFOLLOW on the path lookup operations, and
therefore what you end up with is the link target following the
namei() call in the kernel to resolve the path -- it's resolving the
target, not the link.
Feel free to pass the same path to other functions which take path
arguments, but you will be disappointed when, lacking the O_NOFOLLOW,
they also resolve to the link target instead of the link.
-- Terry
On May 1, 2009, at 11:51 PM, rohan a wrote:
Atleast on my Mac 10.4 there does not seem to be any lchflags. I
have only chflags() and fchflags() available to me.
I will use getattrlist() and setattrlist() which provide
ATTR_CMN_FLAGS to get/set the flags.
On Sat, May 2, 2009 at 12:06 PM, rohan a <email@hidden> wrote:
So doesn't Mac OS provide an API to work on symboic links rather
than its target ?
Something like an lstat().
Thanks.
On Sat, May 2, 2009 at 2:12 AM, Terry Lambert <email@hidden>
wrote:
On May 1, 2009, at 5:07 AM, rohan a wrote:
Hello,
Thanks for this.
1. However, man 2 stat
says that st_flags is of type u_long, but chflags() takes as
argument flags which is u_int.
For 32 but systems, it doesn't matter. For 64 bit systems, it
doesn't care because it's unsigned, so extension to long on LP64
won't change the values. On Leopard and later, it's defined as:
/usr/include/sys/stat.h:int chflags(const char *,
__uint32_t);
so I have to believe you are looking at your 10.4 system again.
2. If I do an lstat() on a file and take its st_flags:
lstat(path, &statbuf);
and then use statbuf.st_flags in the chflags() call, to set the
flags to another file:
chflags(file, statbuf.st_flags);
Is this right?
Careful; you are most likely operating on the link target, and not
the symbolic link itself. It's only recently that you've been able
to modify link attributes rather than link target attributes.
Inferring tto much about symbolic links is a really bad idea, since
it's FS dependent how they are implemented. What Might work in
Leopard on HFS may not work in Tiger on HFS, and that may not be the
same as some other filesystem (i.e. there were a number of
filesystems that supported symbolic links as immediate files,
meaning that all the attributes were inherited from the directory,
since they only existed as a directory entry, and not as real files).
Avoid writing code that assumes symbolic link semantics are the same
between filesystem types. Yes, that means that if you back up on
one system and restore on another, the symbolic links could act
different, and in undesirable ways, unless you go out of your way to
characterize behaviour on each FS type, and each version of an OS
you might be archiving or dearchiving. This is why there are not
50,000 5 star backup/restore tools out there.
-- Terry
On 5/1/09, Dominic Giampaolo <email@hidden> wrote: The stat() /
lstat() API returns st_flags which are "user defined
flags for file".
How do we set these flags back to a file?
Should it be done using the chflags() function call?
As Terry Lambert noted, you use the chflags() call
to set flags on a file. However do not set undefined
bits - only use the bits in /usr/include/sys/stat.h.
Specifically these are:
#define UF_NODUMP 0x00000001 /* do not dump file */
#define UF_IMMUTABLE 0x00000002 /* file may not be changed */
#define UF_APPEND 0x00000004 /* writes to file may only
append */
#define UF_OPAQUE 0x00000008 /* directory is opaque wrt.
union */
and if you're the super-user you can set:
#define SF_ARCHIVED 0x00010000 /* file is archived */
#define SF_IMMUTABLE 0x00020000 /* file may not be changed */
#define SF_APPEND 0x00040000 /* writes to file may only
append */
Keep in mind that most of these bits have defined
meanings in the file system: IMMUTABLE and APPEND in
particular. Bits such as NODUMP are not really used
on MacOS X.
--dominic
_______________________________________________
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