Tag Info

New answers tagged

1

Possibly by failing at defining the file path to be deleted. Your case reminded me a beautiful day that when my homemade remove(path) method tried to remove the root folder because the given parameter was empty string which the OS corrected (!) as the root folder. This may be a similar git bug. Such that: Rebase command wanted to delete a file like ...


4

You may be in luck, and have backup superblocks on the partition. If you can remember the options used to create the filesystem (e.g. you just used defaults), then you can find the locations of the backups like so: sudo /sbin/mkfs.ext4 -n <original_options> <device> The -n is critically important - it is a "dry-run" option that won't write ...


2

First of all, make sure the disk is read-only, so that no more writes happen to it while trying to recover the data. The ext4 superblock is hard to find, because the contents vary a lot, depending on the inode count, block count etc. However, there is a magic signature 0xEF53 (16 bits) that you can try to search for. If you can find the right place, then ...


1

If you hadn't blown away the old ext4, there might have been some hope for fsck to do some repairs and find some intact directory structures. There might actually still be hope for that, by using an alternate superblock that was in the part of the disk you didn't mess up with mkfs. Or if your old FS had a different number of backup superblocks than your ...


2

You can't fix LVM by growing size back to original size, unless you were very lucky and the LV had no fragmentation whatsoever due to previous resizes. Chances are the new LV will have the first 20G or so of your original filesystem but the remaining 780G (or whatever) are scrambled eggs (wrong data, wrong offset, wrong order). And that's assuming you're ...


1

The problem with grep is that it needs to have an entire line in memory. If that line is so large that it doesn't fit in memory, than grep bombs. The only way around this dilemma is to feed small chunks to grep. (which is really what grep should be doing itself, anyway, but it doesn't). Use dd so that you can specify an offset to start at, and use fold or ...


4

I would use strings that way : strings 400Gfile.bin | grep -C 10 searchstring To start at a given offset (eg: 20G), dd if=400Gfile.bin bs=20G skip=1 | strings | grep -C 10 searchstring


5

If you've a snapshot of the filesystem, or a backup, then yes. If you haven't, then no.


0

I can confirm that opening the disc with VLC does bypass the protection. However, when using dd, I had to use this command after opening VLC (discovered by loading the disc and using the directory exposed in VLC). dd if=/dev/sr0 of=image_of_disc.iso Which is different from many posts I have read that say this command should work: dd if=/dev/cdrom ...



Top 50 recent answers are included