[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a9e1e31b909346faa9b398db9fa33ba1@paragon-software.com>
Date: Fri, 4 Sep 2020 12:52:07 +0000
From: Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
To: Mark Harmstone <mark@...mstone.com>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
CC: Pali Rohár <pali@...nel.org>
Subject: RE: [PATCH v2 05/10] fs/ntfs3: Add attrib operations
From: Mark Harmstone <mark.harmstone@...il.com> On Behalf Of Mark Harmstone
Sent: Saturday, August 29, 2020 3:54 PM
> On 28/8/20 5:52 pm, Konstantin Komarov wrote:
> > Hi Mark! Thanks for the feedback. It's reasonable concern, but the open
> > question is how to access those NTFS attributes which extend the DOS
> > attributes. user.DOSATTRIB may be good for FAT32 as DOS attributes are stored in 8bit.
> > However, this does not apply to NTFS (32bit attributes).
>
> I'm not sure why this would be an issue - the obvious way of reading
> user.DOSATTRIB is to use sscanf into an int, and then check for the bits you're
> interested in. The NT FILE_ATTRIBUTE_* values replicate and extend the FAT
> constants used by DOS, so it shouldn't cause any confusion only exposing the
> full 32-bit value.
Hi Mark! First, in v4 we've removed smbd-exclusive access to
user.DOSATTRIB. Overall, we agree that unified access is preferred.
If everyone is fine with sticking to user.DOSATTRIB, we'll remove
other options in next patches.
Powered by blists - more mailing lists