Destroys files if fallocate() is not implemented
Donwulff opened this issue · comments
I would say one of the prime use-cases for "shake" is systems so old that they don't support fe. ext4fs, and hence defrag4fs. Web is full of old articles, which tell you to use "shake" on such old ext3fs machines.
But what happens if you run it now after the patch d984848 ? Well, shake truncates the original file, after which the fallocate() fails. Modern glibc apparently "emulates" fallocate() in such cases, but it really does no good, and in such old systems there appear to be implementations which simply error out. Checking that real fallocate() works would therefore be a good idea. (CMake etc. checks aren't enough, because the syscall exists, it just errors when called on ext3fs)
shake tries really hard not to destroy files, at worst it may let you know that the file has been renamed. The error message should look like failed to allocate space! file has been saved at .... Can you please confirm this is what you are seeing?
That's true, although it means that shake cannot be used on filesystems not supporting (or emulating via glibc) fallocate. The error message is also unclear, at least to me it wasn't apparent that the original file had been truncated (and not deleted, so it can even take a while to notice). For some reason it also seems that hundreds of files on the filesystem I was using it on were truncated, but I've not been able to reproduce it yet (I don't think I ran it in a loop for individual files, but that's distinct possibility too).
user@server:~/shake> find test | sudo ./shake -vv --old=0
IDEAL START END FRAGC CRUMBC AGE SHOCKED NAME
./shake: test/CPackSourceConfig.cmake: failed to allocate space! file has been saved at shakenuXJaF: Operation not supported
user@server:~/shake> ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 14 Dec 11 2018 /lib/libc.so.6 -> libc-2.11.3.so
user@server~/shake> uname -a
Linux server 3.0.101-108.87-default #1 SMP Fri Feb 22 16:42:57 UTC 2019 (10e85a8) x86_64 x86_64 x86_64 GNU/Linux
Updating the system isn't an option currently (heck, there's plenty of embedded/NAS appliances where updating REALLY isn't an option). I guess it could say "file has been truncated and saved" to make it clearer it isn't just inconsequential advisory, but using fallocate() only if it actually works would seem to solve the problems and have it degrade gracefully to how it used to function.