From:	Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
Message-Id:	<199803181542.QAA24816@propus.lu.erisoft.se>
Subject:	Re: Where to get the latest sources for djtar (fwd)
To:	djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
Date:	Wed, 18 Mar 1998 16:42:26 +0100 (MET)
MIME-Version:	1.0

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

Ok. Suppose that your run of djtar runs into the problem of not being able
to create a directory, djtar asks for another name and the user answer with
"1". djtar can't create this directory either, asks the user again, and so
on. Sooner or later the user is feed up with giving directory names that 
djtar can't create, so he answers with "". This would make the unpatched 
djtar skip all the files that was in the directory that wasn't created. 
The patched djtar tries to write the file uncreated_directory/one_file,
discovers that it can't open uncreated_directory/open_file, so ask the 
user for a new name.

Ok?

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

Oh yes, I've looked. But as it was for CDROMs, I didn't think it would apply
here.

> 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 

I don't understand what you mean with (1).

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

Well is it better doing a INT21/36 than calling statfs? Anobody care to 
comment?

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

I'll try that.


Thanks,

							MartinS

- Raw text -