Destroys files if fallocate() is not implemented about shake

[unbrice]

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?

[Donwulff]

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.