linux-ext4 - Re: [PATCH 0/3] Extended file stat functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <23973.1277844061@redhat.com>
Date:	Tue, 29 Jun 2010 21:41:01 +0100
From:	David Howells <dhowells@...hat.com>
To:	Steve French <smfrench@...il.com>
Cc:	dhowells@...hat.com, viro@...iv.linux.org.uk, jlayton@...hat.com,
	mcao@...ibm.com, aneesh.kumar@...ux.vnet.ibm.com,
	linux-cifs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, samba-technical@...ts.samba.org,
	sjayaraman@...e.de, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/3] Extended file stat functions

Steve French <smfrench@...il.com> wrote:

> How does a fs return an "unknown" value for one
> (e.g. version field) ... 0  or -1  or ...

Well, for the new creation time, inode version and data version fields, the
query_flags field has a bit for each that's set if the field contains a value,
and is clear if it doesn't.

See the test program on patch 3.

> One hole that this reminded me about is how to return the superblock
> time granularity (for NFSv4 this is attribute 51 "time_delta" which
> is called on a superblock not on a file).  We run into time rounding
> issues with Samba too.

That sounds like something that should be accessible through statfs.  But it
could be made accessible here too.  It would also apply to FAT, which I
believe has a 2s granularity.

> >  (4) Should the inode number and data version number fields be 128-bit?
> This is tricky for SMB2, if you can also provide a device id (or an object
> id of some sort for the superblock) then 64 bit inode number is ok.

A remote device ID?  That would be possible.  That could be used by AFS to
return the numeric volume ID (32 bits) and by NFS to return the FSID (128
bits).  Would you be using the VolumeGUID (128 bits) for SMB2?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html