To: terra AT diku DOT dk
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: stat()/fstat() for DJGPP, v.02 
Date: Sun, 30 Oct 94 13:45:15 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>

Thank you for taking time to comment on my functions.

>> group, other).  Only user gets WRITE access to a file
>> (unless it has Read-only, Hidden or System bit set).
>
> Why the Hidden/System bit part?

Because under MS-DOS, files which have these bits set are
write-protected, too.  Most DOS programs won't let you write
these without a warning and/or special tricks.

>> 5. Directory size is not reported zero by stat(); the number
>>    of used directory entries (sans the ``.'' and ``..''
>>    pseudo-entries) multiplied by entry size is returned
> This could be expensive and is misleading.  If you create a
> directory with 1000 files then delete them all, the size of
> the directory should not change.

Not too expensive, as my experience shows (stat() is already
an expensive function).  Misleading? not entirely.  For
regular files, sizes are also reported as only the number of
*used* bytes they hold; the last cluster (may be as large as
16KB) is usually incomplete, but this doesn't bother us.  It
is true that rewriting a file usually returns unused clusters
to the system, while deleting files in a directory doesn't,
but to report this slack part of the directory is *indeed*
expensive (you must work on BIOS level and read the FAT for
this), and is totally impossible on networked drives.  So,
I chose a (hopefully useful) compromise.  After all,
directories with a large number of unused entries are rare
(unless you didn't run your favorite defragger for 5 years
or so ;-)

>>  7. Both functions report EXECUTE bits based on file's
>>     extension and the two-byte magic number present at the
>>     beginning of the file.
>
> Again this is expensive.

As of DJGPP 1.12, the existing stat() in the library already
does that, even more expensively (my version includes a long
list of file extensions which are known to *not* be executables,
and so are not searched for magic number).  As my goal was
to eliminate the need for extensive #ifdef'ing when porting
Unix programs, the execute bits had to be handled as close to
Unix as I could, even at a price.

>>   3. I don't know how to obtain time fields for root directories,
> You could use the volume label as a better fall back.  Also, I

A disk is not required to have a label; in fact, most floppies
don't have one.  Even if a label is present, it can easily be
changed, thus changing its time stamp.  In my view, this makes
the label method unreliable.

>                                                          Also, I
> think there are some time stamp in the boot record.  Semi-expensive

AFAIK, there is no time stamp in the boot record, but if you know
otherwise, please tell me where in the boot record it dwells.

Once again, thanks for your comments.