Re: Status of lposix?

[steve donovan <steve.j.donovan@...>]

On Thu, May 28, 2009 at 10:15 AM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
> That's just it.  lfs works for some people, but I have performance/personal
> preference issues with it:
>
> * lfs.dir() returns the filename.  If I want stat information, I have to ask
> for it separately.  It is true this is nice and quick on Linux file systems,
> but on Windows, it is much slower than using FindFirstFile/FindNextFile
> directly.  Those APIs provide the stat information as they go.  The Windows
> Git guys have been working on this exact issue.

OK, that's a good one.  A classic case of a Unix model not being
applicable to Windows for real-world examples.

> * lfs.mkdir() only creates the directory if all parent directories are
> created first.  I prefer a directory creation function I call to do
> everything needed to fully create the directory I ask for.
> * lfs.rmdir() removes a directory only if there are no more files or
> directories in it.  I asked for the directory to be removed, and so I expect
> it to fully remove it.

But these are the expected semantics. Irritating, but a good default.
It is not difficult to write functions (in Lua, e.g. in the pl.dir
module) that do these things explicitly.

>  lfs is missing various useful functions like access() or chmod().

Yes, lfs really should have access().  How is chmod() to be
interpreted on Windows?

> lua-ex handles some of my needs pretty well, but there has been no further
> development on it for a while now.  It is these kinds of reasons that forks
> happen.  I have one fork.  I expect there are others.

I can understand why people might like benign dictatorships,
sometimes.  This can all be very confusing to newbies. If there was a
standardization process that had a chance of catchiing on, I'd be
keen.

steve d.