Re: Setting st_flags returned by stat
Re: Setting st_flags returned by stat
- Subject: Re: Setting st_flags returned by stat
- From: rohan a <email@hidden>
- Date: Sat, 2 May 2009 12:26:42 +0530
Will I be able to use ATTR_CMN_FLAGS on UFS volumes as well?
On Sat, May 2, 2009 at 12:21 PM, rohan a
<email@hidden> 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.
/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