Mail Archives: djgpp/1999/07/25/05:14:31

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: <>
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 

> 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 -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019