 |
lua-l archive |
|
|
||
|
My point was that if you just want a boolean function to detect a softlink, using mode=="link" (or mode =="softlink" if it is the case) would fill the need, no?
Not at all. Because mode is already defined as a field which works like the field of the same name in stat(). If you know that an object is "directory" than you cannot also know it's a "link."
If mode would return all possible attributes of the object, that would indeed solve the problem but it would be backwards-incompatible. (It would, at least on Unix, mean statting and lstatting every object, even if you were only interested in lfs.attributes()-like data.)
If Windows properties are mappable in flags, then we could consider offering a version of lfs.symlinkattributes() in Windows which would contain those properties even if the field names were not the same as the Unix version.
That would be the worst possible solution IMO.Everywhere that you called symlinkattributes() you'd have to include OS-detection code in your application and to have two ways of handling the result. You might rather do something like lfs.win and lfs.unix as OS-dependent sublayers (for those who want OS-specific functions), and an lfs package which unites the two (and chooses the right sublayer for the user).
Attributes(), which is just a wrapper for stat() (and IMO would better be called stat), has been made to work on Windows and Unix, though admittedly with Microsoft's own mappings of Windowsisms into Unixisms (since IIRC it calls the MSVCRT implementation of stat).
So why not the same compromise for symlinkattributes() (which is a real mouthful -- lstat() would be a better name :-)? Chase down the file system data for the link itself...regardless of OS.
Or else make an OS-independent module called lfs with OS-dependent submodules which it selecte automatically at runtime.