On Thu, Jul 22, 2010 at 11:47 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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? > > Linus I haven't been keeping up with this thread, but I believe NTFS has a number of timestamps, not just 3. This blog post references 8 in the left hand column. The 4 standard (most common) ones are: File last access File last modified File created MFT last modified My understanding is that "MFT last modified" has semantics very similar to Linux ctime. But there is not a generic equivalent to NTFS created. Thus if trying to have the Linux kernel match NTFS semantics for the benefit of Samba is the goal, it seems a new field should be preferred instead of having linux ctime try to do different jobs. Greg -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
