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: Fri, 1 May 2009 13:42:17 -0700
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