[PATCH 1 of 5] util: add filestat class to detect ambiguity of file stat

[Yuya Nishihara]

On Wed, 25 May 2016 01:45:09 +0900, FUJIWARA Katsunori wrote:
> At Tue, 24 May 2016 21:58:11 +0900,
> Yuya Nishihara wrote:
> > > +    def isambig(self, old):
> > > +        """Examine whether new (= self) stat is ambiguous against old one
> > > +
> > > +        "S[N]" below means stat of a file at N-th change:
> > > +
> > > +        - S[n-1].ctime  < S[n].ctime: can detect change of a file
> > > +        - S[n-1].ctime == S[n].ctime
> > > +          - S[n-1].ctime  < S[n].mtime: means natural advancing (*1)
> > > +          - S[n-1].ctime == S[n].mtime: is ambiguous (*2)
> > > +          - S[n-1].ctime  > S[n].mtime: never occurs naturally (don't care)
> > > +        - S[n-1].ctime  > S[n].ctime: never occurs naturally (don't care)  
> > 
> > Does it work well on Windows? I'm not skeptical about it, I just question
> > because ctime is platform dependent.
> 
> According to "Remarks" in the document for BY_HANDLE_FILE_INFORMATION
> structure, from which os.lstat() of Python gets st_mtime/st_ctime
> information via GetFileInformationByHandle() API:
> 
>   https://msdn.microsoft.com/en-us//library/windows/desktop/aa363788(v=vs.85).aspx
>     For example, on a Windows FAT file system, create time has a
>     resolution of 10 milliseconds, write time has a resolution of 2
>     seconds, and access time has a resolution of 1 day (the access
>     date).
> 
> I confirmed availability of ctime on FAT-formatted USB memory device.

My concern is ctime is "change" time on Unix, but it is "creation" time on
Windows. So the characteristics would be very different on Windows. That said,
I don't have any particular concern in mind.