LR is not CTRL+C friendly about luarocks HOT 11 CLOSED

Oh, that's a big one.

"Atomically", when dealing with many files and directories in the filesystem is not very feasible, but I understand that it would be ideal to make it "as atomic as possible".

We'd probably need something to handle the Ctrl+C signal (lua_signal?), and also to be able to handle correctly Ctrl+C when performed during external commands that are launched by LuaRocks.

Looks like "Ctrl+C friendliness" could probably evolve in a number of stages.

from luarocks.

If possible, please do some simple fix for the manifest corruption issue first, as it bites us rather sharply :-)

from luarocks.

Any hints on how to reproduce this? Do you know how to trigger a corruption? Simply pressing Ctrl+C while the package is being built doesn't seem to do the trick here.

from luarocks.

It is a tricky one, unfortunately. We only ever see it (I think) because our script installs a lot of rocks and we run it often.

Maybe mount some artificially slowed down FS (sshfs + iprelay? would be cool if that would work, please share your experience), so the write speed is really low, and try hitting CTRL+C while LR is writing?

from luarocks.

Semi-offtopic: I was curious about FS write speed shaping, so I asked a question on ServerFault: http://serverfault.com/questions/358955/filesystem-speed-shaper-for-linux. Let's see if there is an out-of-the-box solution.

from luarocks.

BTW writing to temporary file (manifest.tmp for example), then rename ("ln -f" on unixes) should help

from luarocks.

@avnik, any reason for using "ln -f" over "mv"?

from luarocks.

I mean sequence of
posix.link(name, tmpoldname)
posix.unlink(name)
posix.link(tmpnewname, name)
posix.unlink(tmpoldname)
should be very atomic.

"mv -f" should be enough atomic, if new tmp file created in same filesystem (same folder usually mean same fs, /tmp and /usr/local usually different fs)

from luarocks.

just browsing some old issues;

@agladysh: has the fix by @hishamhm helped resolve your issue? if so can this one be closed?

from luarocks.

Erm. That is a good question.

@avnik ping :-)

from luarocks.

has the fix by @hishamhm helped resolve your issue? if so can this one be closed?

I guess 6.5 years is a good enough timeout :)

from luarocks.