On Mon, Oct 19, 2009 at 1:55 PM, Andreas Dilger <adilger@xxxxxxx> wrote: > On 19-Oct-09, at 11:17, Steve French wrote: >> >> A new version of the format for Samba server related file system >> extended attributes is expected in the next version of Samba so the >> topic of create time and nanosecond timestamps for Linux has come up >> again. Since some file systems don't support storing create time >> (birth time), and none support updating create time, or for that >> matter for storing any nanosecond timestamps at all (a millisecond >> seems like a much longer time today than when the stat structure was >> defined), and dos attributes, Samba server stores these in extended >> attributes, which is awkward on those file systems which store >> (different) versions of these on disk. > > I had proposed in the past that these file attributes be exposed to > userspace as virtual xattrs, e.g. user.cr_time returning a struct > timespec, but the data is stored internal to the filesystem in whatever > format is most efficient for it. We only strictly need user.crtime > for this, but I wouldn't object to exporting other inode attributes in > this way (e.g. user.mtime, user.atime, etc). Yes - the fake xattr approach was the approach that I preferred (since I could do this trivially to cifs, and for ext4 it seems equally easy), but I wonder if this "path based" approach is slightly harder for Samba, since for most cases Samba maps to "handle based" equivalents (when the same operation can come in eitherpath based or handle based - Samba mostly maps to handle based). In cifs I also store dos attributes (as presumably vfat and ntfs could too) which if requested could return the same way (network backup application writers have asked me for an xattr for this before, but I would prefer to use a standard xattr name rather than something cifs specific). As we move to SMB2, all network file operations become handle based (except open). It may be easier for Samba as an ioctl (handle based) rather than xattr (path based) - not sure. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
