Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261760AbVADKfL (ORCPT ); Tue, 4 Jan 2005 05:35:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261731AbVADKfL (ORCPT ); Tue, 4 Jan 2005 05:35:11 -0500 Received: from ppsw-6.csi.cam.ac.uk ([131.111.8.136]:38052 "EHLO ppsw-6.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S261760AbVADKel (ORCPT ); Tue, 4 Jan 2005 05:34:41 -0500 Subject: Re: FAT, NTFS, CIFS and DOS attributes From: Anton Altaparmakov To: "H. Peter Anvin" Cc: sfrench@samba.org, ntfs-dev , samba-technical@lists.samba.org, hirofumi@mail.parknet.co.jp, lkml In-Reply-To: <41D9C635.1090703@zytor.com> References: <41D9C635.1090703@zytor.com> Content-Type: text/plain Organization: University of Cambridge Computing Service, UK Date: Tue, 04 Jan 2005 10:34:25 +0000 Message-Id: <1104834865.26349.32.camel@imp.csi.cam.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6249 Lines: 132 On Mon, 2005-01-03 at 14:24 -0800, H. Peter Anvin wrote: > I recently posted to LKML a patch to get or set DOS attribute flags for > fatfs. That patch used ioctl(). It was suggested that a better way > would be using xattrs, although the xattr mechanism seems clumsy to me, > and has namespace issues. > > I also think it would be good to have a unified interface for FAT, NTFS > and CIFS for these attributes. > > I noticed that CIFS has a placeholder "user.DosAttrib" in cifs/xattr.c, > although it doesn't seem to be implemented. > > Questions: > > a) is xattr the right thing? It seems to be a fairly complex and > ill-thought-out mechanism all along, especially the whole namespace > business (what is a system attribute to one filesystem is a user > attribute to another, for example.) > > b) if xattr is the right thing, shouldn't this be in the system > namespace rather than the user namespace? > > c) What should the representation be? Binary byte? String containing a > subset of "rhsvda67" (barf)? Definitely not c! In NTFS, the "dos attribute flags" are part of the system information attribute which is an entity in its own right, totally separate from extended attributes (and named streams for that matter). So if I were to be thinking in an NTFS-only world I would be inclined to use an ioctl() to access/modify them (i.e. not b either). So if you implement an ioctl() for vfat I will probably be able to provide the same in NTFS with almost zero effort (we already have the code to read and write the attribute flags in the kernel ntfs driver, we just do not provide an interface for it). But please note that it would be best if you could use 32-bits for the flags. At the very least 16-bits though as on NTFS there are currently in use 16-bits in the standard information but the field is u32 sized on disk (little endian) and two of the higher bits are in use in the file name attribute as well and I would not be surprised if more bits get used in future NTFS releases. Tridge already gave you a list of all the Samba dos attributes so here is the full list for NTFS (note they are 100% compatible to the Samba ones and also note in NTFS we always keep the flags in little endian and just define all the constants to be little endian as well - makes life much easier): /* * File attribute flags (32-bit). */ enum { /* * The following flags are only present in the STANDARD_INFORMATION * attribute (in the field file_attributes). */ FILE_ATTR_READONLY = const_cpu_to_le32(0x00000001), FILE_ATTR_HIDDEN = const_cpu_to_le32(0x00000002), FILE_ATTR_SYSTEM = const_cpu_to_le32(0x00000004), /* Old DOS volid. Unused in NT. = const_cpu_to_le32(0x00000008), */ FILE_ATTR_DIRECTORY = const_cpu_to_le32(0x00000010), /* Note, FILE_ATTR_DIRECTORY is not considered valid in NT. It is reserved for the DOS SUBDIRECTORY flag. */ FILE_ATTR_ARCHIVE = const_cpu_to_le32(0x00000020), FILE_ATTR_DEVICE = const_cpu_to_le32(0x00000040), FILE_ATTR_NORMAL = const_cpu_to_le32(0x00000080), FILE_ATTR_TEMPORARY = const_cpu_to_le32(0x00000100), FILE_ATTR_SPARSE_FILE = const_cpu_to_le32(0x00000200), FILE_ATTR_REPARSE_POINT = const_cpu_to_le32(0x00000400), FILE_ATTR_COMPRESSED = const_cpu_to_le32(0x00000800), FILE_ATTR_OFFLINE = const_cpu_to_le32(0x00001000), FILE_ATTR_NOT_CONTENT_INDEXED = const_cpu_to_le32(0x00002000), FILE_ATTR_ENCRYPTED = const_cpu_to_le32(0x00004000), FILE_ATTR_VALID_FLAGS = const_cpu_to_le32(0x00007fb7), /* Note, FILE_ATTR_VALID_FLAGS masks out the old DOS VolId and the FILE_ATTR_DEVICE and preserves everything else. This mask is used to obtain all flags that are valid for reading. */ FILE_ATTR_VALID_SET_FLAGS = const_cpu_to_le32(0x000031a7), /* Note, FILE_ATTR_VALID_SET_FLAGS masks out the old DOS VolId, the F_A_DEVICE, F_A_DIRECTORY, F_A_SPARSE_FILE, F_A_REPARSE_POINT, F_A_COMPRESSED, and F_A_ENCRYPTED and preserves the rest. This mask is used to to obtain all flags that are valid for setting. */ /* * The following flags are only present in the FILE_NAME attribute (in * the field file_attributes). */ FILE_ATTR_DUP_FILE_NAME_INDEX_PRESENT = const_cpu_to_le32(0x10000000), /* Note, this is a copy of the corresponding bit from the mft record, telling us whether this is a directory or not, i.e. whether it has an index root attribute or not. */ FILE_ATTR_DUP_VIEW_INDEX_PRESENT = const_cpu_to_le32(0x20000000), /* Note, this is a copy of the corresponding bit from the mft record, telling us whether this file has a view index present (eg. object id index, quota index, one of the security indexes or the encrypting file system related indexes). */ }; typedef le32 FILE_ATTR_FLAGS; Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/