Don't overwrite creation time if set by make_create_timespec

Ralph Böhme rb at sernet.de
Fri Mar 14 12:13:15 MDT 2014


On Wed, Mar 12, 2014 at 10:23:06AM -0700, Jeremy Allison wrote:
> On Wed, Mar 12, 2014 at 02:40:27PM +0100, Ralph Böhme wrote:
> > On Tue, Mar 11, 2014 at 04:59:03PM -0700, Jeremy Allison wrote:
> > > On Mon, Mar 10, 2014 at 05:59:41PM +0100, Ralph Böhme wrote:
> > > > smb2_create calls dos_mode() after calling SMB_VFS_CREATE_FILE(), as a
> > > > result the creation time as set by make_create_timespec() is always
> > > > overwritten.
> > > > 
> > > > Add a check to dos_mode() that tests for st_ex_calculated_birthtime ==
> > > > true and only then update the creation time with the value from the
> > > > DOS attribute xattr.
> > > > 
> > > > Review appreciated. Thanks!
> > > 
> > > OK, I'm not sure this change is correct. What bug are
> > > you trying to fix here ?
> > 
> > not being able to set st_ex_btime from a VFS module without being
> > overwritten by dos_mode().
> 
> That's what you're trying to achieve, that's NOT what
> you're trying to fix. Please explain the ACTUAL BUG
> in Samba that you're running into.

Well, I thought it would was a bug that dos_mode() unconditionally
writes btime which might already be set by some *stat on some OS and
filesystem.

I'm beginning to understand that my patch is the wrong approach and
that it actually breaks the necessary logic that the DOS metadata
xattr, if present, must overwrite a btime from stat.

> Returning your btime from the Netatalk metadata is
> fine, but if there is a different btime set inside
> Samba's xattr DOS metadata that needs to override
> your metadata.

It would nice if VFS modules would be allowed to take precendence over
the value from the DOS metadata xattr.

> > I see. So what would be needed is a proper way to let VFS modules set
> > btime without dos_mode() overwriting it. *scratches head*
> 
> Again, that's what you think you want to do,
> not what your actual problem is. *Why* do
> you need to do this ?
> 
> Explain *carefully* how you expect btime
> to behave please, and under what circumstances
> this should be different from what smbd
> currently does.

I'll try. This is from the perspective of an OS X client:

somemac:~ ralph$ mount | grep /Volumes
//ralph at fedora.local/AFP on /Volumes/AFP (afpfs, nodev, nosuid, mounted by ralph)
//ralph at fedora.local/SMB on /Volumes/SMB (smbfs, nodev, nosuid, mounted by ralph)

"AFP" and "SMB" mounts give access to the same directory tree shared
via Netatalk and Samba. "SMB" uses my new VFS module vfs_apple.

somemac:~ ralph$ rm /Volumes/AFP/file 
somemac:~ ralph$ touch /Volumes/SMB/file

Set two different creation dates for AFP and SMB:

somemac:~ ralph$ SetFile -d 01/01/2001 /Volumes/SMB/file
somemac:~ ralph$ SetFile -d 01/01/2002 /Volumes/AFP/file

Note that setting when the creation date via SMB, the vfs_apple VFS
module will update the creation date in the Netatalk metadata too. In
this case the second SetFile is via AFP, this ensure that the dates
for Netatalk and Samba are different.

When reading creation date via SMB, vfs_apple will try to read the
creation from Netatalk metadata if there is any. And Netatalk metadata
should take precedence over Samba's DOS xattr.

Without the patch reading the creation date via SMB returns the date
from the Samba DOS xattr:

somemac:~ ralph$ GetFileInfo /Volumes/SMB/file | grep created
created: 01/01/2001 01:01:00

With the patch SMB returns the creation date from the Netatalk
metadata:

somemac:~ ralph$ GetFileInfo /Volumes/SMB/file | grep created
created: 01/01/2002 01:01:00

As said, I know my patch breaks some necessary logic. Any other
suggestion how to approach this?

Add something like st_ex_mutable_birthtime to stat_ex and set it to
false in stat until Linux has xstat() (or whatever else) and a
function for setting btime?

Thanks!
-Ralph

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de,mailto:kontakt@sernet.de


More information about the samba-technical mailing list