This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: timestamp confusion

Hash: SHA1

According to Löwis on 6/20/2007 5:45 AM:
> I'm confused that there exist at least four different (constant)
> timestamps that can be displayed by 'dir /T:W', 'dir /T:A', 'dir /T:C', and
> 'ls -l --time=ctime'. I expected the times displayed by 'dir /T:C' and
> 'ls -l --time=ctime' to be the same.

Welcome to Unix emulation coupled with Windows timestamp stupidity.

NTFS tracks four different times:
access time, modification time, creation time, and change time

Some network file systems can support all four, many do not.  At which
point, you are at the mercy of what the file system supports, as well as
what Windows supports when mapping to the remote file system.

FAT only tracks three times (no change time), and with awful resolution
(up to 2 second granularity, with different resolution per timestamp).
Cygwin fakes ctime on FAT by reusing mtime.

Cygwin, like Linux, obeys POSIX, and treats ctime as change time (ie.
ctime will always be set to the timestamp of the last action that modified
the file or its metadata, and there is no way to fake it; even though you
can use touch to fake the last mtime).  Cygwin snapshots (which will
become cygwin 1.7.0) also support the BSD notion of birthtime, which maps
to Window's creation time.

Windows goes against the grain (surprise), and thinks that ctime means
creation time.  No other operating system does this.

> I'm also confused that 'ls -l --time=atime' apparently modifies the atime of
> the file.

You're reading the metadata of a file - and in some cases on cygwin, that
includes reading contents of the file to decide if it is executable; which
means it can be enough of an access for the file system to consider
updating the atime of that file.  Sorry, but that's life.

> I'm also confused by the fact that 'type 400000066.err' does not change the
> access time displayed by 'dir' (but that's obviously no Cygwin problem).

Are you referring to the Windows type or the bash type here?  You are
right that we have no control over Window's type.  Bash's type does not
stat files, so I don't think it should be updating access times.

> On the local hard drive everything works as expected:
>   ~/tmp/foo$ ls -l --full-time --time=ctime foo
>   -rw-r--r-- 1 loewjoha Domänen-Benutzer 4 2007-06-20 12:37:32.475250000 +0200 foo

When looking at timestamps, you may be interested in the stat command -
less typing, and you get more information.

> I stumbled across this when I tried to use find(1) to find files with an
> access or modfication time not later than a certain day, but find(1) found
> rather unexpected files. 

Ah, but some versions of find had bugs in this area.  Try the newest find

> So, the question I'd actually like to ask is: What is the Right Way (tm) to
> find all files in a directory tree (on a network drive) that have been
> accessed (alternatively modified) in the last x days?

With find -atime or find -mtime.

- --
Don't work too hard, make some time for fun as well!

Eric Blake   
volunteer cygwin coreutils/findutils maintainer
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]