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 known...

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 that!

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 people.

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 outstandingly dysfunctional.

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 the kind.

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 this.

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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to