ctime is "creation time" on windows, "ctime" on unix

[isaacs]

It'd be better if "ctime" meant the same thing on Windows as it does on Unix.

Yes, of course, most platforms treat "ctime" as "creation time" on Windows, and in fact, even some Unix tutorials and blogs say that "ctime" is "creation time". But we should not contribute to the confusion!

Libuv and Node aim at cross-platform portability. The disparate semantics causes problems in some cases, especially since the "creation time" of a file is not updated if it is deleted and then re-created within 15 seconds. Please make "ctime" on windows mean "changed time", as in, "the last time that any of the file's metadata was changed".

A cursory perusal of google shows that there's no way to know on NTFS when a file's metadata was changed. Perhaps this can be closed as "can't fix".

If this is unpossible, then that's too bad. However, it would still be nice to explicitly provide "creation_time" on the stat object. Something like this maybe?

#ifdef not_sure_offhand_what_this_should_be_for_darwin_and_freebsd
#define CREATE_TIME(x) x.st_birthtime
#elif defined(WIN32)
#define CREATE_TIME(x) x.st_ctime
#else
#define CREATE_TIME(x) 0
#endif

#ifdef WIN32
#define CTIME(x) 0
#else
#define CTIME(x) x.st_ctime
#endif

[bnoordhuis]

Windows issue. Assigning to you, Bertje.

[jsstorm]

I agree that those file time stamps should be consistent for a low level cross platform API, or at least well documented with the difference for platforms.

I also confused with the ctime on unix, and treated them as creation time as windows. and later realized unlike windows, there is no creation time for unix systems.

For windows system, call GetFileInformationByHandleEx with FileBasicInfo can obtain the FILE_BASIC_INFO structure which contains file ChangeTime, which should be the same as ctime on unix. file writing operations and file attribs or ACL changing will result this time stamp updated.

But GetFileInformationByHandleEx is only supported for windows vista and later. also the ChangeTime only works on NTFS file system. FAT, FAT32, exFAT is not supported.

So maybe the libuv API can try to obtain what it can for the current os and file system, and fill zero values for those not supported, and high level applications can choose what to use depending on what they need and the system currently running.

[piscisaureus]

I can do it for windows, for any version of windows. (Although, note that FAT doesn't track change time and I don't know offhand what windows would make of it.

The question is, are we going to expose "creation time" somehow? I know it's not possible on linux but it is on darwin. I think @bnoordhuis should for once accept that his favorite OS isn't perfect in every area and that we should document that st_btime (or, alternatively, st_crtime?) is always 0 on unix.

[bnoordhuis]

uv_stat_t has a st_birthtim field as of f9e6029, that would be the logical place to store it. It's zeroed on Linux and other platforms that don't have a 'creation time' concept.

[piscisaureus]

@isaacs, @bnoordhuis - It'd be good if you guys could at least read the comments in fs__stat_handle as added in 7ba9f4e.

[bnoordhuis]

Looks okay to me.

[piscisaureus]

@bnoordhuis Is that a LGTM for all patches, or did you just read the comments?

[isaacs]

I heartily +1 the suggested API changes here. I don't agree with all the TODO comments, however. Making chmod simply fail on Windows is probably worse than what we have now. The read-only bit being a deletion protection (rather than an execution protection) is certainly an oddball discrepancy, but it's an easy enough one to work around. However, having ctime be a time, but not the same time, is really hazardous.

Rubber-stamp on the commits themselves. We really ought to get birthtime exposed in Node!

[bnoordhuis]

Is that a LGTM for all patches, or did you just read the comments?

I mostly looked at 7ba9f4e but the other commits seem okay too. As to chmod() behavior on Windows, I don't have a strong opinion on how it should work.

[piscisaureus]

@isaacs I am not super certain about fs_chmod but I know that what we do now is pretty useless. Let's talk about this on our tuesday call.

[piscisaureus]

Landed in 7f75695...20a8e58

[isaacs]

Maybe a silly question, but is BasicInfo.ChangeTime updated when the mode/times/etc. metadata is updated?

I'm guessing it ought to, otherwise what's the point of having "ModifiedTime" as well.

[jsstorm]

Yes, the ChangeTime will be updated either file data or metadata changed, tested with change file mode (attrib)/times (touch)/ACLs.

[prasannavl]

Just a quick clarification. So now, in Windows, there's really no way to get the "creation-time" (which is what ctime generally refers to on Windows, as opposed to *nix) of a file, without using the Win32 API directly? Am I correct in assuming that, or is there it exposed somewhere in the form of birthtime?

Would be nice if birthtime is exposed atleast on Windows (this has been exposed in a standard way in the Win32 API for ages) and the *nix kernels that support it, while on filesystems that do not support it, simply return an undefined or null.

[bnoordhuis]

@prasannavl It's exposed as uv_stat_t.st_birthtim.