[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH2r5mvCJ=fPt5BgwFubJ+HWo+a0EHOTNoXxTt0NOhMC=V+GcQ@mail.gmail.com>
Date: Fri, 17 Jan 2025 11:51:54 -0600
From: Steve French <smfrench@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Amir Goldstein <amir73il@...il.com>, Pali Rohár <pali@...nel.org>,
ronnie sahlberg <ronniesahlberg@...il.com>, Chuck Lever <chuck.lever@...cle.com>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org,
linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org,
Steve French <sfrench@...ba.org>, Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: Immutable vs read-only for Windows compatibility
On Fri, Jan 17, 2025 at 11:39 AM Darrick J. Wong <djwong@...nel.org> wrote:
>
> On Fri, Jan 17, 2025 at 05:53:34PM +0100, Amir Goldstein wrote:
> > On Wed, Jan 15, 2025 at 12:59 AM Darrick J. Wong <djwong@...nel.org> wrote:
<...>
> > Looking at the FILE_ATTRIBUTE_* flags defined in SMB protocol
> > (fs/smb/common/smb2pdu.h) I wonder how many of them will be
> > needed for applications beyond the obvious ones that were listed.
>
> Well they only asked for seven of them. ;)
>
> I chatted with Ted about this yesterday, and ... some of the attributes
> (like read only) imply that you'd want the linux server to enforce no
> writing to the file; some like archive seem a little superfluous since
> on linux you can compare cmtime from the backup against what's in the
> file now; and still others (like hidden/system) might just be some dorky
> thing that could be hidden in some xattr because a unix filesystem won't
> care.
>
> And then there are other attrs like "integrity stream" where someone
> with more experience with windows would have to tell me if fsverity
> provides sufficient behaviors or not.
>
> But maybe we should start by plumbing one of those bits in? I guess the
> gross part is that implies an ondisk inode format change or (gross)
> xattr lookups in the open path.
>
We have talked about some of these missing flags in the past, but the
obvious ones that would be helpful i (e.g. is used in other operating
systems when view directories in the equivalent of the "Files" GUI is
checking FILE_ATTRIBUTE_OFFLINE to determine whether to query icons,
and additional metadata for files). In the past Unix used to have
various ways to determine this, but it is fairly common for files to
be tiered (where the data is in very slow storage offline - so should
only be opened and read by apps that really need to - not things like
GUIs browsing lists of files) so that attribute could be helpful.
The other two obvious ones (missing in Linux but that some other OS
have filesystems which support) discussed before were
FILE_ATTRIBUTE_INTEGRITY_STREAM which could be set for files that need
stronger data integrity guarantees (if a filesystem allows files to be
marked for stronger data integrity guarantees) , and
FILE_ATTRIBUTE_NO_SCRUB_DATA that indicates integrity checks can be
skipped for this particular file.
--
Thanks,
Steve
Powered by blists - more mailing lists