Re: [Gnu-arch-users] Dirname caching for leroy's tla on cygwin

[John Meinel]

address@hidden wrote:

> > that's actually tla searching for its metadata...
> > and sometimes it wants to make a new path, and searches
> > for the sub-part that already exists to add new subdirs.
>
>
> So what I need to know is when do we have an authoritative answer about
> a directory? Should we be caching somewhere other than
> pathcompress_compress_path?
>
>
> > that's actually the problem with =dirnames mapping that I would have liked
> > to have solved before implementing caching...

Well, in one sense caching isn't implemented. At least it doesn't work 
so it is disabled :)

> > and that's the beauty of the "dos-8.3" hack: always compress, always
> > "authoritative"...

Well, I like the general idea of the dos-8.3 hack. I wonder though, if I 
ask for the 8.3 version of a directory that doesn't exist, what does it 
tell me?

And I'm curious about the speedup from caching these names, but it might 
be possible because you don't have to do the system call.

The only thing that keeps =dirnames around for me is because of rdp. 
Specifically what if you want to publish an archive on a win32 machine 
so that other people have access to it. A linux implementation isn't 
going to be calling the win32 api.

Also important is a Mac port of tla. I don't know if Mac has the same 
path limitations that win32 has.


I think using 8.3 filenames in the win32 port will probably be okay. You 
still have the problem that trying to delete your working directory with 
Explorer will fail. I'm not sure how to work around that. Maybe a tla 
command "nuke {arch}".

The only other problem is that we really only have < 200 characters to 
work with. Simply because people are going to want working directories. 
And it is easy to get 50 chars worth of working directory before you 
even get {arch}.

I will play around with the tarball that you uploaded. I was thinking to 
have you check it into your repository, though I don't know what format 
you are going to want to use.

RDP's work puts pathcompress into libhackerlab under vu, and then makes 
tar/patch/diffutils use hackerlab. I don't know if it would be better to 
switch and have a separate pathcompress lib that libhackerlab depends on 
as well as tar/patch/diffutils, etc.

Probably either one would work. I don't really care if it's a dll 
because it's going to be small, so statically compiling it is fine for me.

John
=:->