Re: [ANN] LuaFileSystem 1.3.0 Released

["Andre Carregal" <carregal@...>]

On 10/27/07, Duck <duck@roaming.ath.cx> wrote:
> >> Perhaps a portable "issoftlink()" function for
> >> both platforms?
>
> > Wouldn't it be enough to return lfs.attributes(filename).mode
> > == "link" in this case?
>
> Errrrr, isn't that where we started? The mode field is a single, specific
> value, not a list (table). So the things it can tell you about any file
> system object are limited. In particular, it can't tell you that a
> directory is also a soft link, which makes it impossible reliably to
> prevent cycles when walking a directory tree.

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?

If you were in Windows, that would be all the information available,
but if you were in Unix you could then call lfs.symlinkattributes()
for more details.

> lfs.symlinkattributes() now gives a way around this, but on Unix only,
> which rather squashes the concept of portability mentioned in the lfs docs.

True, but I see no problem in having a two layer API, where the first
is guaranteed to be portable while the second would be considered
platform specific. You just need to know how to compromise.

> I am thinking that
>    issoftink()
> and
>    ismountpoint()
>
> functions would be nice to have...but on Windows I'm not sure how to find
> if a directory actually is an _active_ mount point (has another volume
> mounted in it) instead of simply finding out that, pre-Vista, it's a
> junction.

While I don't know how to get this info in Window, but assuming we are
talking about boolean properties, I still think we could use mode as
string based "bit map" and still offer lfs.attributes() as the
portable way to ask for information, while functions like
lfs.symlinkattributes() could be reserved for platform specific needs.

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.

Again, the bias of a common API and an extension one...

André