Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Date:	Fri, 20 Oct 2000 17:53:20 -0400
Message-Id:	<200010202153.RAA20964@envy.delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	cygwin AT sources DOT redhat DOT com
Subject:	Re: Why does ls report some directory dates as future?

OK, I think I figured out why this is happening.  On FAT filesystems,
there is no directory entry for the root directory, so there is no
place to store the timestamp.  Sorry, just isn't there.  Win32 returns
a zero when asked for it.

However, there was a bug in cygwin in that it was incorrectly
converting the zero that Win32 returns for it's timestamp, rather than
just preserving the zero-ness.

So, I changed cygwin (will be in tonight's snapshot) to preserve the
zero-ness.  Now, when you mount a FAT root over an existing directory,
"ls -l" will show a time of around Jan 1 1970, the "epoch" of POSIX
time.  It's still not informative, but at least it's not a random time
in the future.  stat() on such directories will return 0 in the
st_mtime field.

What DJGPP does, which may be difficult to implement in Cygwin, is
that it looks for the volume label on such drives and uses that time
as the root's time, assuming that the volume label was created when
the drive was formatted.  Alternatively, one could scan the whole root
directory and choose the earliest timestamp found.  If anyone wants to
volunteer to do either of these, let us know!

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -