From: lhall AT rfk DOT com (Larry Hall) Subject: Re: ls -p very slow 5 Nov 1997 21:06:41 -0800 Message-ID: <2.2.32.19971105215929.009b93a4.cygnus.gnu-win32@ma.ultranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Earnie Boyd" , garbanzo AT hooked DOT net Cc: gnu-win32 AT cygnus 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 AT cygnus DOT com" with one line of text: "help".