Date: Wed, 18 Mar 1998 17:09:18 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Where to get the latest sources for djtar
In-Reply-To: <199803181256.NAA19087@propus.lu.erisoft.se>
Message-ID: <Pine.SUN.3.91.980318165211.21959B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


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.