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@xxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
