Prev: nfs client hang
Next: [PATCH net-next] sysfs: add attribute to indicate hw address assignment type
From: Volker Lendecke on 22 Jul 2010 09:00
On Thu, Jul 22, 2010 at 01:14:47PM +0100, David Howells wrote:
> Jan Engelhardt <jengelh(a)medozas.de> wrote:
>
> > Linux already has a creation time field, it's called otime (there is no "b"
> > in "creation"), and you will find scattered fragments of that all over the
> > kernel (foremost, fs/jfs/, now btrfs, and I also notice sysvipc having
> > something with that name).
>
> It is? It's called crtime in Ext4. st_btime, however, would be compatible
> with BSD's stat, and Samba would just use it by way of autoconf magic if it
> appeared.

Samba has the following check:

# recent FreeBSD, NetBSD have creation timestamps called birthtime:
AC_CHECK_MEMBERS([struct stat.st_birthtimespec.tv_nsec])
AC_CHECK_MEMBERS([struct stat.st_birthtime], AC_CHECK_MEMBERS([struct stat.st_birthtimensec]))

and the supporting code around that. "birth" might also be
where the "b" comes from :-)

Volker
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Volker Lendecke on 22 Jul 2010 11:40
On Thu, Jul 22, 2010 at 08:14:42AM -0700, Linus Torvalds wrote:
> > # recent FreeBSD, NetBSD have creation timestamps called birthtime:
> > AC_CHECK_MEMBERS([struct stat.st_birthtimespec.tv_nsec])
> > AC_CHECK_MEMBERS([struct stat.st_birthtime], AC_CHECK_MEMBERS([struct stat.st_birthtimensec]))
> >
> > and the supporting code around that. "birth" might also be
> > where the "b" comes from :-)
>
> Oh wow. And all of this just convinces me that we should _not_ do any
> of this, since clearly it's all totally useless and people can't even
> agree on a name.
>
> Let's wait five years and see if there is actually any consensus on it
> being needed and used at all, rather than rush into something just
> because "we can".

The nice thing about this is also that if this is supposed
to be fully usable for Windows clients, the birthtime needs
to be changeable. That's what NTFS semantics gives you, thus
Windows clients tend to require it.

Just as a hint, nothing that Linux should necessarily have
to be bothered with, this is Samba's duty :-)

Volker
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Allison on 22 Jul 2010 12:30
On Thu, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote:
> On Thu, Jul 22, 2010 at 8:36 AM, Volker Lendecke
> <Volker.Lendecke(a)sernet.de> wrote:
> >
> > The nice thing about this is also that if this is supposed
> > to be fully usable for Windows clients, the birthtime needs
> > to be changeable. That's what NTFS semantics gives you, thus
> > Windows clients tend to require it.
>
> Ok. So it's not really a creation date, exactly the same way ctime
> isn't at all a creation date.
>
> And maybe that actually hints at a better solution: maybe a better
> model is to create a new per-thread flag that says "do ctime updates
> the way windows does them".
>
> So instead of adding another "btime" - which isn't actually what even
> windows does - just admit that the _real_ issue is that Unix and
> Windows semantics are different for the pre-existing "ctime".
>
> The fact is, windows has "access time", "modification time" and
> "creation time" _exactly_ like UNIX. It's just that the ctime has
> slightly different semantics in windows vs unix. So quite frankly,
> it's totally insane to introduce a "birthtime", when that isn't even
> what windows wants, just because people cannot face the actual real
> difference.
>
> Tell me why we shouldn't just do this right?

No, ctime isn't the same as Windows "create time". Windows
"create time" semantics are that the timestamp is set to
current time on file creation, but afterwards anyone with
sufficient access can then modify it (!). Which is different
from the "birthtime" spec on *BSD, as they can't be modified.

Currently on *BSD we look for our special EA containing any
modified create times on a file, and return that as "create
time" if found, if not we return the st_birthtime from the
stat struct. That works well enough for systems where you
don't want to allow birthtime to be changed. Having said
that I'm not sure how they cope with doing restores to
a filesystem where you would need to set st_birthtime :-).

Jeremy.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Trond Myklebust on 22 Jul 2010 13:20
On Thu, 2010-07-22 at 19:03 +0200, Jan Engelhardt wrote:
> On Thursday 2010-07-22 18:40, Linus Torvalds wrote:
>
> >On Thu, Jul 22, 2010 at 9:27 AM, Jeremy Allison <jra(a)samba.org> wrote:
> >> On Thu, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote:
> >>> Tell me why we shouldn't just do this right?
> >>
> >> No, ctime isn't the same as Windows "create time".
> >
> >Umm. What kind of reading problems do you guys have?
> >
> >I know effin well that ctime isn't the same as Windows create time.
> >THAT WAS MY POINT.
> >
> >But the fact is, th Unix ctime semantics are insane and largely
> >useless. There's a damn good reason almost nobody uses ctime under
> >unix.
>
> I beg to differ. ctime is not completely useless. It reflects changes on
> the inode for when you don't you change the content. It's like an mtime
> for the metadata. It comes useful when you go around in your filesystem
> trying to figure out who of your co-admins screwed up the permissions on
> /etc/passwd... and if the mtime is the same as that of the last backup,
> I can at least have a reasonable assurance that it was /only/ the
> metadata that was tampered with. (SHA1 check, yeah yeah, costly on large
> files.)

Errr... Only if you eliminate utimes() from your syscall table.
Otherwise it is trivial to reset the mtime after changing the file
contents.

Cheers
Trond

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jim Rees on 22 Jul 2010 13:30
Linus Torvalds wrote:

I personally think that Unix ctime is insane. There is no real reason
why "write()" should change mtime, but "chmod" changes ctime. It was
just a random decision way back when...

I believe it was done that way so "dump" could backup just the inode and not
the data if only the inode had changed. Full history here:

http://blog.plover.com/Unix/ctime.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3 4
Prev: nfs client hang
Next: [PATCH net-next] sysfs: add attribute to indicate hw address assignment type