Konstantin Khomoutov schreef op 02-08-2016 13:21:
On Mon, 1 Aug 2016 13:44:55 +0200 (CEST)
Xen <l...@xenhideout.nl> wrote:
> git wiped the file from disk. I worked very hard on that file
> (several days( and I really hope this can be recovered. I could not
> find a solution on the web.
I hope the advice that was given to you would work.
Yes, it worked.
In general if you want to be absolutely sure that a file is
You unplug the power cord ASAP.
I would advise against such an "take no hostages" approach: when you
unplug the power cord you might surely lose changes in other files
while trying to save the original one.
That is going to be entirely irrelevent unless you have explicit files
open that you are editing but have not saved.
Therefore, the advice you give is circumstantial and surely cannot be
considered a good reason to never do it.
This is exactly what I mean with not giving credit to actual recovery
tools. They are almost never mentioned, and some people even boldly
state that "you have lost all your data" when usually this is not going
to be the case.
Also you were not the original person, so my answer was not really
directed at you personally.
And I did not see a reply from this person so I could not really have
If one wants to quickly bring a Linux system down for forensic
activities on its filesystems, I'd recommend to do Alt-SysRq-s followed
Alt-SysRq-o, which would sync the filesystems and then halt the system.
I had never known about those keys until just before ;-). It's good
advice, but I don't have that key on my keyboard. I never knew Linux had
So unless you can use that measure instead, the best advice you can
still give anyone is to unplug the power.
Also if syncing filesystem buffers is the only thing that differentiate
your approach from mine, then that is not going to help you with open
files you have not yet saved.
Also, the default Linux options are really really bad; even Linus has
said so. But they are still the defaults. And you can (and should
really) bring those defaults down to reasonable levels. The default 30
second sync window is not helpful. The default 10% of RAM in Dirty
Buffers is also not helpful.
A 5 second sync-window (dirty-time) is going to be much better for most
So if you did that, chances of having dirty buffers stick around from
saves you did 25 seconds ago, will be much slimmer ;-).
The actual risk of losing other kind of files is just completely
irrelevant as compared to a file you have worked on for 3 days because
at most there is going to be a 30 second window and even that is
So in practical terms, no, the chances of their being open filesystem
buffers in the dirty cache when you have done git rm -rf ., have taken
at least 30 seconds to find out what has happened, and you have done
nothing in the meantime, is just going to be zero.
There is hardly ever going to be an occasion that this is going to
matter or happen. The only dirty writes will usually be log files.
Sure, it's possible that synchronizing FS buffers would re-use the
space once occupied by the deleted file but I'd call it a reasonable
For what, for not losing dirty buffers that don't exist?
There is no trade-off. In this situation everyone would at least be
puzzled for 30 seconds and try to do some "ls" and "vdir" or anything of
It is at that point that you realize, Okay, what am I going to do.
And it is at that point that unplugging the cord becomes an option. And
people should know about it, that's all I am saying.
Linux is not like Windows that will suddenly fail to boot if you do
The /etc/ directory is never really written to and /var can probably
handle a sudden shutdown certainly if it is only going to be log files.
Even if you did not want to do it immediately, if you wait those 30
seconds it is going to be near-equivalent on a desktop.
Unless something like Baloo is running, perhaps. Dangerous stuff ;-).
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.