Re: [ANN] LuaFileSystem 1.3.0 Released

[Tomas Guisasola Gorham <tomas@...>]

	Hi

> >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).
	Why OS-detection could not be detected at compile time?
Don't you think this could be resolved with some #ifdefs?

> 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.
	We are not against an implementation of symlinkattributes
for Windows.  We just don't know how to implement it?  Do you have
any idea?

> Or else make an OS-independent module called lfs with OS-dependent 
> submodules which it selecte automatically at runtime.
	Maybe I am missing something, but I cannot see why one
would like to select a Linux-dependent module on Windows or a
Windows-dependent module on a different OS.  I believe this modules
could not even compile!

	Regards,
		Tomás