Date:	Sun, 25 Jul 1999 12:11:51 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Fredrick Backman <fredrick DOT backman AT pmail DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: file size
In-Reply-To:	<379AEFD8.713A1AC@pmail.net>
Message-ID:	<Pine.SUN.3.91.990725120629.27488f-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 25 Jul 1999, Fredrick Backman wrote:

> Perhaps you misunderstood. What I meant was that part of the info that
> DJGPP's stat() returns is redundant because of the fact that DOS stores
> less info about each file compared to what UNIX does.

That's mostly not true in the DJGPP case, see below (and also see the 
documentation of `stat' in the library reference).

> I might be mistaken but is it not the case that in DOS, st_atime and
> st_ctime contain the same value as st_mtime?

On plain DOS, yes; on Windows 9X, no.  If the OS supports 3 file times, 
then `stat' returns 3 different values; if it doesn't, they are returned 
equal.

> And st_nlink is always 1?

No, not always.  Directories get st_nlink as on Unix: the number of 
subdirectries plus 2.  Files get st_nlink = 1, but that's not redundant 
info: the number of links to a file on DOS/Windows is *really* 1.  In
fact, if it isn't 1, this means you need to run CHKDSK/ScanDisk on your 
drive, because FAT/VFAT volumes cannot cope with these calamities.

And, in case you wonder: st_ino is also returned as a meaningful datum 
(the number of the first cluster allocated to the file).

- Raw text -