Mail Archives: djgpp/1994/10/31/16:38:16
>> 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,
> Really? I guess that the raw disk-reading functions are BIOS-level
> and wouldn't be available for network drives, but it's not the FAT you
> need to read, it's a regular file with the directory bit set (except
Alas, DOS won't let you even open() the file with a directory bit
set, let alone read it.
> So couldn't you try some dodge like
> resetting the directory attribute (I suppose this might also require
> BIOS-level functions) and reading the raw directory data?
Sorry, but no. You can't reset this bit by any method short of
rewriting the disk sector of the parent directory, but that's the same
as reading the sector(s) of the directory itself (and of the FAT, to
track the cluster chain). Also, going BIOS is impossible on remote
drives. For some curious reason DOS guards its subdirectories so
dearly you almost won't believe it! It insists on treating them as
special and tricks you into using directory-specific functions, even
as we all know they are just files, no more, no less.
The above is AFAIK, of course, I would cheerfully learn something
new here. Anybody?
>> I chose a (hopefully useful) compromise. After all,
> Be that as it may, I'm not sure I agree with this compromise. One can
``Compromise'' is not really a good word here. Assuming that I'm right
and you can't get at the real size of the directory unless you read
large parts of the disk, what other choice do we have? Even if we decide
to go ahead and read those sectors, what about remote drives? I would
say this is by far more often case than a hypothetical defragger. (And
btw, defraggers really *have* to access the disk on the sector level
anyway, so they won't suffer from stat() doing an imperfect job here, but
will find true directory size by themselves.)
That said, I'm still prepared to solve this in a better way, provided
that somebody shows me one, and if this djgpp community accepts it
(I wrote those critters to be included in the C library, not just for
fun).
> I didn't run a defragger for a long time because my favorite one
> was Norton Speedisk, which chokes on big drives (this is an old
> version, about Norton Utilities 5.0).
Come on, Norton is at v8.0 for at least 6 months now! Would you
postpone upgrading to the next version of GCC for such a long time?
EZ>> 3. I don't know how to obtain time fields for root directories,
> A lot of DOSes (well, IBM's, anyway) automatically put serial numbers
> on floppies. I believe this is done using the volume label bit
Somebody already answered this: the encoding of date/time in the
boot record is irreversible. As for the volume label, if this is
what you djgppers out there want, it's no big deal to do it this
way. Should we vote?
> One way to deal with it might be to set up the sources so that
> individuals could create their own preferred order of checking the
> various alternatives easily. I think that it's probably a good idea
If you are talking about recompiling parts of the library to make some
functions act differently, then the sources are there to be changed.
But if you have in mind some global variables which change behavior
of library functions, then we are effectively inventing djgpp-specific
standard, and I believe others should say what they think about it.
Then it could be incorporated into the code.
The problem of default behavior should still be resolved, though.
- Raw text -