lunarmodules/luafilesystem

LuaFileSystem is a Lua library developed to complement the set of functions related to file systems offered by the standard Lua distribution.

luafilesystem's Issues

build failed - flexibility for configurations needed

It is a bit more right way to build the library:

diff --git a/config b/config
index cfd4c6a..f545f74 100644
--- a/config
+++ b/config
@@ -4,10 +4,10 @@
PREFIX=/usr/local

System's libraries directory (where binary libraries are installed)

-LUA_LIBDIR= $(PREFIX)/lib/lua/5.1
+LUA_LIBDIR= $(shell pkg-config --libs lua5.1)

Lua includes directory

-LUA_INC= $(PREFIX)/include
+LUA_INC= $(shell pkg-config --cflags lua5.1)

OS dependent

LIB_OPTION= -shared #for Linux
@@ -17,7 +17,7 @@ LIBNAME= $T.so.$V

Compilation directives

WARN= -O2 -Wall -fPIC -W -Waggregate-return -Wcast-align -Wmissing-prototypes -Wnested-externs -Wsh
-INCS= -I$(LUA_INC)
+INCS= $(LUA_INC)
CFLAGS= $(WARN) $(INCS)
CC= gcc

(END)

Does LFS works with lua 5.2.3?

I installed LFS via luarocks, and then executed require 'lfs' on the interpreter, and that is what I got:

version mismatch: app. needs 503, Lua core provides 502
stack traceback:
    [C]: in ?
    [C]: in function 'require'
    stdin:1: in main chunk
    [C]: in ?

I don't know what these numbers mean, but the version mismatch struck a cord in my head. Does LFS works with lua 5.2.3?

I use Linux Mint 17.3.

Establish and follow a uniform coding style (guideline)

Commit 3789521 already pointed out that the current C source follows a mix of indentation rules, and that it would be desirable to return to a (more) uniform coding style:

About indentation: currently parts of lfs.c use 2 spaces and parts use 8. It would be nice to slowly switch to one of styles over some time, as code is being touched here and there. 2 spaces seem preferrable as it's what Lua itself uses.

Tools like AStyle might help with this task.

Personally I prefer four spaces over two, as I find that more readable.

mkdir -p option

Current mkdir only supports single depth directory creation.
Enable options to create parent directory as well?

Missing tags for releases

The latest releases are missing a tag,

it would be easier to download them if they had one.

lfs.attributes segfaults

Hi,
lfs.attributes segfaults, if one uses as second argumend a table, and as third argument some nil value:

mrac@schreibmaschine:~$ lua
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> require "lfs"
> =lfs.attributes( "/bin", "mode" )
directory
> return lfs.attributes( "/bin", "mode", NILVALUE )
directory
> return lfs.attributes( "/bin", { } )
table: 0x1c91500
> return lfs.attributes( "/bin", { }, NILVALUE )
Speicherzugriffsfehler
mrac@schreibmaschine:~$ 

Tested this on Linux and Windows, same behaviour.

can you please add is_file and is_dir checks

luarocks.fs already have it, can we add the checks for is_file and is_dir ?

Thanks.

readlink() proposal

there is no 'readlink()' facility in luafilesystem. just having attributes() and symlinkattributes() is cumbersome to use.

I'd like to propose following ideas, and if accepted i can implement them and send a patch:

• just implement lfs.readlink(name[, recursive]) which returns the file pointed too or 'nil' when not a symlink. If recursive is true or a number then resolve the link recursively (for n times or until reaching a final file, checking that there is no loop)
• extend the lfs.attributes() function returning a .link field when the given filename was a link. This can be a array of recursive link expansions or just the final name to which it resolves. in case of a loop, stat() already fails.

Release bugfix.

Bug #26 cause application crash on simple loop for ... in lfs.dir(...) do ... end.
May be it worth release bug fix and put it in LuaRocks/LuaDist?

lfs and non-native language paths (win)

There is no possibility as for now to work with paths in different languages, like
D:\CH 漢語\DE üöäß\RU ёйцу\EN.txt

lfs.attributes'D:\\CH 漢語\\DE üöäß\\RU ёйцу\\EN.txt'
returns following error:
cannot obtain information from file 'D:\CH 漢語\DE üöäß\RU ёйцу\EN.txt'

Other functions fail too.

issue solved, sorry, delete please

LFS not installing correctly.

Hi, I was making a lua application(duh) and I needed LFS. I went and downloaded LuaRocks and did:

luarocks install luafilesystem

It came up with this(http://pastebin.com/uJgq3BZs)

Can someone help me install/guide me to a guide to install. Also, if this won't work, what do the devs mean by adding the binary to the C path?

currentdir() fails on long path

here is how it looks like when path length exceeds PATH_MAX - 1:

$ printf 'pwd length: %d\n' "${#PWD}" ; lua -e 'assert((require "lfs").currentdir())'
pwd length: 4100
lua: (command line):1: Numerical result out of range
stack traceback:
    [C]: in function 'assert'
    (command line):1: in main chunk
    [C]: in ?

expected behavior is to try getcwd() with larger buffer if ERANGE thrown

lfs.dir behaves badly with pcall

Using Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio

Regular for f in lfs.dir("dir") works fine...

> lfs = require("lfs")
> for f in lfs.dir(".") do print(f) end
.
wop
..
blah

Using a pcall fails with the for loop

> res, files, iter = pcall(lfs.dir, ".")
> =res
true
> for f in files(iter) do print(f) end
stdin:1: attempt to call a string value
stack traceback:
    stdin:1: in main chunk
    [C]: ?

Using a pcall works, but only using explicit while loops to get a separate string each time

> res, files, iter = pcall(lfs.dir, ".")
> f = files(iter)                       
> while f do                            
>> print(f)
>> f = files(iter)
>> end
.
wop
..
blah

It would be nice if this would work nicely.

Windows code not x64 compatible

dir_info defines handle as a long. While this works for 32 bit, it should really be intptr_t, which is works in both 32 and 64 bit. It's also the type expected by _findfirst, _findnext and _findclose.

Time to deprecate lfs.rmdir?

(In favour of os.remove, which since 5.0 has acquired the ability to remove empty directories too; it would even be possible to do

lfs.rmdir = os.remove

Given that os.remove removes both files and directories, it seems pointless to keep a function that removes only directories, especially when there is no function which removes only files, either in core Lua or LFS.)

Missing tags

Webpage talks about version 1.6.2 but last tagged version is 1.5.0 .-??.

Directory iterator that returns an errno on error

lfs.dir throws an error if e.g. access is denied.

Instead, I'd like to know the type of error via returning errno.

Please update links from web pages

Point to the github bug tracker (assume you mean to use it rather than the LuaForge tracker) and the github git (rather than the now-defunct LuaForge CVS).

This will make it easier for users to file bugs and track development; thanks!

Listing files with Chinese names on PC with Western code page does not work (Windows)

LFS on Windows uses ANSI APIs like _findfirst instead of wide char version like _wfindfirst.
This causes issue when trying to list file named in Chinese letters on a Windows PC using some western code page.
Current implementation returns name like "????.html" where the Chinese letters are replaced with question marks, and fetching attributes does not work.

I've modified 1.6.3 code to use wide char APIs, and it works correctly for this use case.

Note that the change breaks compatibility in the sense that on Windows dir() call now returns UTF-8 encoded name instead of ANSI (so that the name does not get modified to ????)
Using such name to load file with Lua's io.open should work for files that it worked before (where file name uses ANSI characters), but not with Chinese named files. That's OK, because it did not work before either.

lfs.zip

lfs.lock_dir really a good idea?

Locking is a complicated subject, and lfs.lock_dir implements its own mechanism. It's about 100 lines of C, and it's far from clear that it's useful or robust. It is hard to tell whether the behaviour is the same on Window and non-Windows system (it doesn't look like it). There are no tests for it. Something similar could easily be implemented using lfs.lock in a few lines of Lua. I suggest it be removed, or, failing that, tests be added. Contrary to the documentation, there seems to be no second parameter to check for staleness either on Windows or non-Windows systems (if a second parameter is passed, it is ignored).

In summary, this has the air of application-specific code that is not ready to be put in a library.

Unused static int pushresult() on Windows

When using more strict checking (e.g. -Wall or -Wunused-function) on platforms where _WIN32 is defined, the compiler may complain:

lfs.c:152:12: warning: ‘pushresult’ defined but not used [-Wunused-function]
 static int pushresult(lua_State *L, int i, const char *info)
            ^

This is due to the fact that make_link() won't use pushresult() and will always fail with pusherror() instead.

It might be desirable to either
a) encapsulate the pushresult declaration with a #ifndef _WIN32 / #endif block, or
b) change the pusherror(L, "make_link is not supported on Windows"); to pushresult(L, -1, "make_link is not supported on Windows"); instead.
(I actually prefer the latter.)

[EDIT] An assignment like errno = ENOSYS; could also be a good idea, so the subsequent strerror(errno) returns something meaningful.

Regards, NiteHawk

Release tarballs

Somewhat related to #23, it seems that it's not currently possible to download any released tarball.

luafilesystem homepage not listed at its luarocks page

At https://luarocks.org/modules/hisham/luafilesystem, there's no link pointing to the luafilesystem homepage (I'm presuming it should be the github page).

Symbolic link under windows

Is there any reason to not implement Simbolic links under windows? I tryed the following quick and dirt mod and it seems to work.

#ifdef _WIN32
#include <windows.h>
#include <winbase.h>
#endif
static int make_link(lua_State *L)
{
        const char *oldpath = luaL_checkstring(L, 1);
        const char *newpath = luaL_checkstring(L, 2);
#ifndef _WIN32
        return pushresult(L,
                (lua_toboolean(L,3) ? symlink : link)(oldpath, newpath), NULL);
#else
  int err = CreateSymbolicLink(newpath, oldpath, 0);
  if (!err) return pusherror(L, "make_link is not supported on Windows");
  else pushresult(L, lua_toboolean(L,3), NULL);
#endif
}

Note: I compiled with mingw and _WIN32_WINNT=0x0600 .

lfs declares a global

This is considered bad practice nowadays.

On the other hand, fixing this in the code may break a lot of stuff out there (with the trivial fix of changing require("lfs") to local lfs = require("lfs")).

Should we make this change in the code?

One-character change to build for 5.2 alpha

Change luaL_reg to luaL_Reg. That's it!

Missing documentation for attributes.permissions

The permissions field is not documented in the manual.

attribute mode

Calling the file type "mode" is a bit odd, as "mode" usually refers to the actual read/write protection. I am working on an luafilesystem compatibility layer for ljsyscall and already have a mode field, so I have called it "filetype" and have a compatibilty fix to return as mode in the lfs layer, as "filetype" seems a bit closer to what this field returns...

realpath for luafilesystem

Hello
luafilesystem should have a realpath like luaposix.
It is very difficult to implement in lua with the existing lfs API.
Some times, I only require luaposix only for this feature...

Regards,

Odd behaviour of lfs.attributes and lfs.mkdir on Windows

Assume your are on Windows 7 with some HDD v:/. There is also a folder v:/rel.
Try this:

    print(lfs.attributes( "v:", "mode" ))
    print(lfs.attributes( "v://", "mode" ))
    print(lfs.attributes( "v:/", "mode" ))
    print(lfs.attributes( "v:/rel", "mode" ))
    print(lfs.attributes( "v:/rel/", "mode" ))
    print(lfs.attributes( "v:/rel//", "mode" ))
    print(lfs.mkdir("v:/s"))
    print(lfs.mkdir("v:/s/"))
    print(lfs.mkdir("v:/t/"))
    print(lfs.mkdir("v:/t"))

Result:

nil     cannot obtain information from file 'v:': No such file or directory
directory
directory
directory
nil     cannot obtain information from file 'v:/rel/': No such file or directory
nil     cannot obtain information from file 'v:/rel//': No such file or directory
true
nil     File exists
true
nil     File exists

So lfs.attributes does accept "/" at the end of a path, except it is the root directory.
Then you can even use "//".
But lfs.mkdir doesnt care at all.
Spend hours to find this bug in my code.
How is the situation on Linux? I didnt even try it yet.
Do I have to write a wrapper around each lfs function which expects a filepath, to find out what filepath does mean for each function and each platform?

doc for setmode

The documentation is rather unclear, it says setmode "Returns the previous mode string for the file" when it actually returns a bool and the previous mode. WOuld be good to make this clear...

Missing documentation for link

There is no entry for lfs.link in the manual.html documentation page.

LICENSE file

Can you add the license as a text file at the top level called LICENSE or COPYRIGHT - it is hard to find in the documentation, and this is also what is used for eg automated license checking of software.

lfs.dir does not raise an error for not existing path on Windows

lfs.dir with not existing path raise error on *nix but not on Windows.
I think error path not found/file not found shold be considered not as error but just as empty resultset.
At least it should be same on all platforms.

Handling of second argument of lfs.attributes

There is a feature that I think is not documented: if a table is passed to lfs.attributes as the second argument, it is filled with attributes instead of a new table. Otherwise if the second argument is not a string it is ignored. Should this be mentioned in the docs or removed?

cygwin things

see patches in
http://www.mail-archive.com/[email protected]/msg00166.html

manual ancor mistake

Hello,

I don't know if the https://keplerproject.github.io/luafilesystem/manual.html page is generated but there are some little mistake in the section ancor names.

• lfs.chdiris ok with manual.html#chdir
• lfs.currentdir is manual.html#getcwd should be manual.html#currentdir
• lfs.lock_dir is manual.html#chdir should be manual.html#lock_dir
• lfs.dir is ok with manual.html#dir
• all others seems also ok.

The source code :

<dt><a name="chdir"></a><strong><code>lfs.chdir (path)</code></strong></dt>
...
<dt><a name="chdir"></a><strong><code>lfs.lock_dir(path, [seconds_stale])</code></strong></dt>
...
<dt><a name="getcwd"></a><strong><code>lfs.currentdir ()</code></strong></dt>
...
<dt><a name="dir"></a><strong><code>iter, dir_obj = lfs.dir (path)</code></strong></dt>

Regards,

don't support use "~"

This is my test program.

print((require "lfs").attributes("", "mode"))
nil cannot obtain information from file `'
print((require "lfs").attributes(".", "mode"))
directory

I use OS is Mac 10.10

Release 1.7.0

I think there are enough small fixes for 1.6.3 to justify a new patch release.

Bug in lfs_unlock_dir (win32)

Hi, there is a bug in lfs_unlock_dir (win32). Here is a fixed version:

static int lfs_unlock_dir(lua_State *L) {
  lfs_Lock *lock = luaL_checkudata(L, 1, LOCK_METATABLE);

  // BUGFIX: lfs_unlock_dir can be called multiple times for the same object.
  //         For example if lock:free is called manually.
  //         Then lfs_unlock_dir will be called always
  //         again, as soon as the LOCK_METATABLE is collected by GC.
  //
  //         This can lead to strange file errors later on, like closing
  //         another file, which now has been assigned the same handle...
  if(lock->fd!=INVALID_HANDLE_VALUE) {    
    CloseHandle(lock->fd);
    lock->fd=INVALID_HANDLE_VALUE;
  }

  return 0;
}

Solaris: get_dir - getcwd zero length

Passing getcwd a length of zero returns NULL on Solaris 10 / SPARC. MAX_DIR_LENGTH+1
works better. Have done only minimal testing since I do not use this function. Found the problem
running supplied test program.

static int get_dir (lua_State *L) {
char *path;
if ((path = getcwd(NULL, MAX_DIR_LENGTH+1)) == NULL) {
lua_pushnil(L);
lua_pushstring(L, getcwd_error);
return 2;
}
else {
lua_pushstring(L, path);
free(path);
return 1;
}
}

Build error using luarocks

I have an

Error: Build error: Failed compiling object src/lfs.o
uname -a
Linux 94.242.221.61 2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

Full luarocks listing: http://pastebin.com/raw.php?i=TVdcKDNE
Other libraries installs well

link error

everytime when i'm trying to install
c:\lua\lua52.dll : fatal error LNK1107
shows up

LARGE_FILE configuration (for small embedded linux)

Buildroot (http://buildroot.uclibc.org/) is a set of Makefiles and patches
that makes it easy to generate a complete embedded Linux system.

Buildroot could build a C library with or without LARGE_FILE support.

So, please define _FILE_OFFSET_BITS, _LARGEFILE64_SOURCE & _LARGE_FILES
in Makefile (or config) instead of in the plain C source src/lfs.c.

cross-link: https://bugs.uclibc.org/show_bug.cgi?id=2359

installing on windows fails with LNK1107 (lua 5.2)

Can't install using luarocks on windows 10 with lua 5.2

c:\Users\soapdog\prog\lua\luarocks-2.4.0-win32>luarocks install luafilesystem
Installing https://luarocks.org/luafilesystem-1.6.3-2.src.rock
cl /nologo /MD /O2 -c -Fosrc/lfs.obj -IC:/lua/include src/lfs.c
lfs.c
link -dll -def:lfs.def -out:lfs.dll C:/lua/lua52.dll src/lfs.obj
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

C:\lua\lua52.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x330

Error: Build error: Failed compiling module lfs.dll

library

cross-platform inconsistencies in `stat` function

In tinkering with this, I've found that paths like /home, /home/ /home/chris and /home/chris/ are valid when this is compiled on linux, but on mingw the situation is different.

C: is not valid, but C:\ is valid. But, C:\Program Files is valid, while C:\Program Files\ is not valid, and stat returns that it is not a directory.

IMO the stat function should be modified so that it consumes any trailing path separators, then puts one back if the result is then 2 characters and the 2nd is ':'. (First part of this is more important than the second.)

symlink oddities

Two suggestions about symlinks:

1. Rather than not defining symlinkattributes on Windows, simply define LSTAT_FUNC to be STAT_FUNC on Windows. This simplifies things, because users no longer have to test whether symlinkattributes is defined before calling it. Calling it on Windows simply returns the same as calling attributes, which makes sense, because on Windows there are no symlinks, and calling lstat on Unix for a non-symlink returns the same as stat, so symlinkattributes for a non-symlink on Unix returns the same as attributes.
2. At the moment there is no way to create a link. If you agree, I would be happy to provide a patch for POSIX (it's trivial, as I can copy the code from luaposix), and no doubt someone else can do the same for Windows.

mingw32 build with MSVCR80

I have an installation (followed this receipt: http://www.thijsschreijer.nl/blog/?p=772 ) of Lua 5.1 with mingw32 under Win8.1 (64 Bits) environment.

Everything runs smooth with "luarocks install xyz-module".
-> even luasocket runs as expected ;-)

"luarocks install luafilesystem" builds a "lfs.dll".
However if I use it, Windows complains about e.g. "_findfirst" not found in ...lfs.dll".

The reason is that Microsoft renamed "_findfirst" to "_findfirst32" - what a great idea...

How to overcome this issue?

Kind regards,
Helmut