From owner-freebsd-fs@FreeBSD.ORG Thu Mar 2 17:36:11 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F0FA16A420 for ; Thu, 2 Mar 2006 17:36:11 +0000 (GMT) (envelope-from mday@apple.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9DE943D49 for ; Thu, 2 Mar 2006 17:36:10 +0000 (GMT) (envelope-from mday@apple.com) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k22HaAJe028864 for ; Thu, 2 Mar 2006 09:36:10 -0800 (PST) Received: from [17.202.43.217] (doomsday.apple.com [17.202.43.217]) by relay6.apple.com (Apple SCV relay) with ESMTP id 751A3253; Thu, 2 Mar 2006 09:36:10 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Day Date: Thu, 2 Mar 2006 09:35:55 -0800 To: conrad@mac.com X-Mailer: Apple Mail (2.749) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-fs@freebsd.org Subject: Re: Add a file flag for "hidden" files? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 17:36:11 -0000 Hi Conrad, On Mar 1, 2006, at 11:59 PM, conrad@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