Mail Archives: djgpp-workers/1998/03/18/10:11:32
On Wed, 18 Mar 1998, Martin Stromberg wrote:
> Two things to note: if it can't create the directory, it just asks the
> user again and again.
That's the intention. The user should press Enter to exit the loop.
> Secondly, it stopped the skipping functionality.
> When the user gives up, because he can't create the directory and gives
> an empty string as reply, djtar still tries to create the directory when
> the next file in the archive is the_directory_that_can_be_created/file.
Sorry, I don't follow you. Could you please describe an example of
archive contents which triggers such problems, and what happens when
djtar unpacks it onto a full floppy, so I could debug this?
> Well, I'm not sure it is that expensive. You see statfs() does a
> INT21/some_numbers.
I guess you haven't looked at `statfs' from the latest alpha release.
`statfs' is HUGE, it's much more than a single Int 21h call; most of the
rest is to support reporting true size of CD-ROMs which are not reported
by calling DOS function 36h.
You could of course only put a call to the DOS function 36h inside
`mkdir' and save all the CD-related trouble. But: (1) that function
lies on FAT32 drives; and (2) it *is* more expensive than many other DOS
functions because DOS needs to scan the entire FAT to report the free
space. In contrast, e.g. `access' only accesses a directory entry of a
single file.
But if you think getting `mkdir' return ENOSPC is so very important, go
ahead submit a patch that calls 2136 and let DJ judge whether to include
it.
> This is what I used to measure (from memory):
Your test program gets overly optimistic results because in most
configurations the FAT of the disk(s) is question will be in the disk
cache after the first call. Try inserting a call to `_flush_disk_cache'
libc function between each two calls, and I think you will see a *big*
difference.
- Raw text -