I've run into some unfortunate interactions between MacOSX resource
forks and non-HFS filesystems. In my particular case I'm working in NFS
mounted directories (from a Linux server), but this problem may occur
with other non-HFS filesystems.

What I know about OS X is basically derived from poking it with a stick
and seeing what happens.  My descriptions may be technically incorrect;
please correct them.

OS X creates two files in the non-HFS filesystem for each real file; one
for the file contents, the other for the Mac specific resource fork
(with a prefix of ._).  For example, here's what you get when running

luarocks unpack luafilesystem-1.5.0-2.src.rock:

        % ls -a
        .                                       luafilesystem-1.5.0
        ..                                      luafilesystem-1.5.0-2.rockspec
        ._luafilesystem-1.5.0-2.rockspec        luafilesystem-1.5.0.tar.gz
        ._luafilesystem-1.5.0.tar.gz
        

There's an asymmetric behavior on deletion. If the "real" file is
deleted first, the resource fork file will be *also* be deleted.  If you
delete the resource fork file first, the real file is *not* deleted.

This causes problems when iterating over directories to move things (as
is done in rep.deploy_files()).  If the real file is moved first (that
is, copied and then deleted) then attempts to move the resource file
will fail with a message like:

stat: /zzzz/lib/luarocks/rocks/penlight/0.9.5-1/lua/pl/._test.lua: stat: No 
such file or directory

because the resource file will have been deleted when the real file was
deleted.  There's no guarantee as to which order lfs.dir() will return
the directory entries, so it can be a bit non-deterministic.

I've "fixed" this by modifying the code to ignore files that begin
with ._ but that seems like an awful kludge.  A cleaner approach might
be to allow the call to lfs.dir to be wrapped on a platform specific
basis to filter out "bad" files.  I've run out of tuits to proceed,
however.

Diab

P.S.  To get luarocks to exhibit this behavior I manually unpack and
build the rock from source.  Running build or install directly on the
rock seems to use /tmp which is on an HFS file system.


------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Luarocks-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/luarocks-developers

Reply via email to