Tag Info

New answers tagged

1

I'd highly recommend that you start with existing tools. As they are all open source, you can see how they are written. If you really want to write your own utility from scratch, you'll probably need to start with reading and understanding this page: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout That page may not be complete, and referencing ...


3

I'm not totally sure what you did there, but if the command in your question is the one you ran, you should just be able to reverse it: for f in * do echo mv -v "$f" "${f%"#_*"}" done Please don't remove the echo from that command until you're sure it works, but, just to explain why I think it will, here's what I did: for f in $(seq 100) do echo $f > ...


1

OP and I worked through this; see comments & chat for details. First, to find the problem process and location, this line in /etc/init/mountall-shell.conf /sbin/sulogin was changed to /usr/bin/ltrace -S -f -o /root/sulogin-ltrace.log /bin/sulogin Excerpt from log: 837 crypt("password", "x") = nil 837 strcmp(nil, "x" <no return ...> 837 --- ...


0

If I understood correctly, you have already fixed the volume, even though you have a lost+found directory which may or may not have critical files. What is going on now that's blocking the VM from booting? It still can't find the boot device? Your fdisk -l output seems a bit off to me. Have you considered the possibility that only the partition table was ...


0

Assuming you're on a Linux host as well (you didn't mention that). You can always try the Network Block Device (NBD) option:- sudo modprobe nbd max_part=16 sudo qemu-nbd -c /dev/nbd0 <path to your vdi file> ls -lh /dev/nbd0* <lists all the partitions on the vdi> Choose which of the partitions you want to mount (eg 1st partition), then: sudo ...


0

If you are abe to boot the guest OS then I think you need to install a package which will work as a recovery tool for your file system.Remember the packege will change from Filesystem to file system.Few which i know are available at for ext4 http://extundelete.sourceforge.net/ you can also check this out ...


1

No way to recover, as simple as that. As a side note, doing dd is not a perfect way to backup files. For future cases, consider using tools like dar - you want some compression, incremental backup would also allow you to save huge amount of time and disk space in most cases.


4

If you do not have backups, your data wasn't important. It's gone. There is no undo. Especially not with encryption involved. something that produces output > /dev/somedisk overwrites data on the device. Whatever is overwritten can not be restored, so your only chance would be if you noticed and cancelled it right away. Then probably only the first few ...


0

Sounds like the file still in use (opened by other application) Try these steps Identify PID of the application that is still using the file by lsof <fielname>, let's say 12345 for example Go to /proc/12345/fd directory, hopefully you see a link that links to the file you want Try to copy it to another location


3

Most probably lost. During the reboot, your system would have written to disk many times. I know it's too late now, but the second you noticed you'd deleted the file you should have physically powered off the machine (not gracefully shut it down - pull the power cord). At that point you could have booted with a recovery CD/USB ensuring that the disk where ...


3

Error code 13 is EACCES - an access violation. You don't have permission to read from the device. Run the command as the superuser, i.e. use sudo extundelete ....


2

Make sure to avoid unnecessary multiple overwrite passes with shred. E.g. use shred -n 1 without anything else. The problem with secure file deletion (with git and in general) is that every time you edit, clone, switch branches, etc. a new file (or set of files) is created, possibly in a different physical location. Thus an unknown amount of copies is ...


4

Forget about shred, it spends a lot of time doing useless things and misses the essential. shred wipes files by making multiple passes of overwriting files with random data (a “Gutmann wipe”), because with the disk technologies of 20–30 years ago and some expensive laboratory equipment, it was possible (at least in theory) to recover overwritten data. This ...


2

I think that since there are so many small files in a Git repository, it's going to take a long time for shred to delete them and write over the old data. I would suggest doing something a little different and use tmpfs to store the data in RAM. Then, when you are done, you simply unmount it and you don't have to worry about the data being stored anywhere on ...



Top 50 recent answers are included