Re: ls -p very slow

[Derek Young <derek at biddersedge dot com>]

Chad Loder wrote:

> That's pretty inefficient...sounds like a problem with how link
> information is stored in general. I know it's not easy to do this kind of
> thing with Microsoft's file systems, but maybe there is a way to speed
> this and related procedures up.
>
> A couple of ideas...one of which has already been implemented by someone
> (see about 5 messages back in this list), I think?
>
> 1) Keep it simple, stupid - only scan files with the System attribute set,
> make sure that all links get this attribute set when created.
>
> 2) Store a binary table of links somewhere on disk, scan thru that for
> links corresponding to what directory you're in. Or just make a hidden
> file in each subdirectory which contains link info for all the files in
> that subdirectory...that way you don't have to (*gasp*) open and close all
> the files every time you want to process which are links (e.g., ls -p or
> similar). Maybe this is too complicated...
>
> -chad
>
> On Mon, 3 Nov 1997, Earnie Boyd wrote:
>
> > It's true.  The link information is stored as text within the link file
> > itself.

NTFS supports extended file attributes (user defined) doesn't it?  Could an
extended attribute be used to hold the destination of the link instead of
storing it within the file?  The file would always be empty.  This way all the
link information is stored within the directory and following links would be
much faster.  Of course FAT doesn't support extended attributes, so links
would still have to live within the file in this case.

-- derek


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".