Add a file flag for "hidden" files?

[Mark Day]

Hi Conrad,

On Mar 1, 2006, at 11:59 PM, conrad at mac.com wrote:

> This is great with MS' SMB servers, and also with local  
> filesystems, as they can easily have UF_HIDDEN added.

Yeah, George is eagerly awaiting the bit so he can use it in SMB.

>   What are you thinking for other filesystems, for remotely served  
> filesystems, that is, which for whatever reason don't read/write  
> UF_HIDDEN?

If they can pass the bit through and have it preserved somewhere,  
then do that.  (If the server doesn't understand the meaning of the  
bit, then at least preserving it for clients seems better than  
ignoring it or returning an error.)

Otherwise, I suppose they'd have to treat it like any other flag bit  
that they don't understand, or the server doesn't support.  I assume  
that means returning an error if the caller attempts to set  
UF_HIDDEN.  Looking at the error codes listed for chflags(2) [in the  
online FreeBSD man page], there is no EINVAL listed, but there is  
EPERM and EOPNOTSUPP.  I'm not sure which one I'd choose.

I can also see an argument that such a file system should just ignore  
the UF_HIDDEN bit and not return an error because the flag is meant  
as a hint to applications, not meant to be enforced by the file system.

FYI, Mac OS X has a mechanism for a file system to tell its clients  
which functionality it supports (volume capability bits, returned by  
the getattrlist(2) call).  In Mac OS X, I'll be adding a new volume  
capability bit that indicates whether a volume supports the hidden  
flag.  The Carbon framework, which will be the major user of the  
hidden flag, is expected to check the volume capability bit and not  
even attempt to set the UF_HIDDEN flag on file systems which don't  
support it.  It will instead use the invisible bit of the Finder  
Info, which would probably be stored in an AppleDouble file on such a  
file system.

-Mark