Re: Meaning of file flags

[Greg Troxel <gdt%lexort.com@localhost>]

I just pulled out "The Design and Implementation of the 4.4BSD Operating
System".  It talks about immutable, append-only, and nodump on page 263.
There is no mention of "archive".

The book is also clear about 16  bits of user flags and 16 bits of
system flags.  chflags(1) is confusing about this, and chflags(2) is
better, showing that there are system flags and user flags (SF_ and
UF_).

It turns out there are more flags in sys/stat.h than are documented in
chflags(2):

/*
 * Definitions of flags stored in file flags word.
 *
 * Super-user and owner changeable flags.
 */
#define UF_SETTABLE     0x0000ffff      /* mask of owner changeable flags */
#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 */
/*      UF_NOUNLINK     0x00000010         [NOT IMPLEMENTED] */
/*
 * Super-user changeable flags.
 */
#define SF_SETTABLE     0xffff0000      /* mask of superuser changeable flags */
#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 */
/*      SF_NOUNLINK     0x00100000         [NOT IMPLEMENTED] */
#define SF_SNAPSHOT     0x00200000      /* snapshot inode */
#define SF_LOG          0x00400000      /* WAPBL log file inode */
#define SF_SNAPINVAL    0x00800000      /* snapshot is invalid */

where we see that there is perhaps a relationship, or at least a bit
reuse, between NODUMP and ARCHIVED.

The three undocumented flags appear to be implementation details and not
part of the syscall interface.

But, reading the sources, I see that the archive bit was indeed added
for MS-DOS compat.  Still, it's far from clear what it means in BSD
other than that it enables read/write access to an archive bit in the
underlying filesystem.  This seems to come from Lite in 1994, but I'm
running out of the will to conduct software archaeology.

So perhaps we should describe it as

  archive bit set in underlying foreign filesystem

and perhaps deny setting it in filesystems that don't implement an
archive bit.

(Probably, the use of this bit is now historical, as it seems at best
awkward for backups, in that one of course wants to make backups to
different media sets, to be able to restore precisely without adding
back deleted files, and to have deduplication.)