Re: ls -p very slow

[Larry Hall <lhall at rfk dot com>]

At 06:23 AM 11/5/97 PST, Earnie Boyd wrote:
>>On Tue, 4 Nov 1997, Chad Loder wrote:
>>
>>> Hmmm...I always thought shortcuts were those bloody *.LNK files which 
>are
>>> only valid from the GUI (they're just files, maybe with .INI 
>syntax?). If so,
>>> then I can't see how that would help. It's odd that MS didn't do 
>symbolic
>>> linking with NTFS. At least they have tab filename completion on NT's 
>DOS box
>>> though...
>>
>>Shortcuts are those bloody .lnk files, but not just available to the 
>GUI
>>proggies, but to all Win32 programs, afaik they don't have INI style
>>syntax.  They do however have various API functions that would probably
>>provide a [small] speedup.  I'm thinking that the stat functions (or
>>whatever ls is using) would only check .lnk files for shortcuts, and if 
>it
>>_is_ a shortcut, then the .lnk is truncated within gnu-win32, and if 
>it's
>>not a shortcut then, it's treated as a regular file (with the .lnk
>>extension).
>>
>
>Don't forget about the .pif files which are shortcuts to executables.
>

Keep in mind that any attempt to provide a viable new underpinning for 
the workings of symbolic links must encompass ALL of the functionality
of symbolic links to be seen as generally useful.  Symbolic links work
for any type of file and for directories.  Shortcuts only work for files.
This, I believe, is the reason these have not been seriously look at as
an alternative to the current symbolic link implementation.  Personally,
I think Sergey has the right idea with his implementation.  It has always 
seemed to me the a symbolic link an attribute of the file.  Certainly, if
someone replaces the current symbolic link implamentation with one that
makes use of shortcuts, the implementation will still need to either open
the short cut file to figure out its a shortcut or base the determination
on some extension to the file name (i.e. .lnk).  I'd be surprosed to find
that shortcut files are significantly faster to open than any other type
of file so I can't see much benefit to a change in this regard.  Using some
extension to recognize these files is a really bad way to go (I've always
felt a file type is an attribute of the file too, not something that you
tack onto a file name).  However, if one were to use this as the basis 
for determining a symbolic link, why bother even creating a shortcut file?
Just tack the extension onto the end of the symbolic link file name and
you're done.  Unless I'm missing something about this issue, I really don't
see any benefit to moving from the current implementation to shortcuts (or
extensions) for symbolic links.  There's nothing to be gained and plenty to
loose as far as I can see.

BTW, it is rumored that NT 5 will have symbolic links implemented as part
of the file system.  Of course, even if this is true and it works well,
this still won't help WinLose 9x users since Microsoft continues to ignore
the fact that FAT file systems really offer no value over NTFS....

Larry

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