I haven't done much fuzz testing either, but here's two ideas:
Write some zeroes into the middle of the file. Use dd with conv=notrunc. This writes a single byte (block-size=1 count=1):
dd if=/dev/zero of=file_to_fuzz.zip bs=1 count=1 seek=N conv=notrunc
Using /dev/urandom as a source is also an option.
Alternatively, punch multiple-of-4k holes with ...
a partial solution
dd if=/dev/zero count=100 bs=1k of=fs.fat
mkfs -t vfat fs.fat
mount fs.fat /mnt ## as root
# cp some file
umount /mnt ## as root
cp fs.fat fs.ref
vi fs.ref ## change some bytes
cp fs.ref fs.sampleX
now you have a good fs (fs.fat) and a corrupted one (fs.ref)
sudo mount -t vfat fs.ref /mnt
mount: wrong fs type, bad option, bad ...
(I know this is an old question, I came across this problem myself and got my FS back to life without ddrescue, so I'll share the expericence for anyone else encountering this)
Ext filesystems store backups of the superblock -- for an occasion just like this one.
First, determine the locations of the backups (make sure you have the -n option! otherwise ...
The most common way to verify the integrity of downloaded files is to use MD5 checksums. This assumes that the site you are downloading from actually published MD5 checksums of their files. You can verify a MD5 checksum by creating your own checksum of the downloaded file and comparing it to the published checksum. If they are identical the file you have ...
The other answers seems mostly concerned with hardware errors. Let me list some software-caused corruptions:
LF replaced with CRLF.
CR removed. (Even if not followed by LF)
Extra Null bytes inserted.
Extra Unicode "Byte Order Mark" inserted.
Character set converted from UTF-8 to Latin-1 or vice versa.
DOS EOF-character(#1A) deleted, even when not at End Of ...
Suspending implies that the data you were working with is in the memory. This state will be lost if you run out of power. If you were writing a forum post, for example, it will be lost, but nothing more serious would happen. Think that it's less serious than unplugging and removing the battery, since the computer can sync before and even delay the suspension ...
If you're looking for advanced filesystems for general-purpose computers in the Linux world, there are two candidates: ZFS and BTRFS. ZFS is older and more mature, but it's originally from Solaris and the port to Linux isn't seamless. BTRFS is still under heavy development, and not all features are ready for prime time yet.
Both filesystems offer per-file ...
The return code of the command used to download the file will tell you if the command executed successfully or not. Typically, a return code of 0 denotes success and any non-zero number denotes an error. You can access the return code through the $? variable.
A basic example using wget would go:
wget foo.tgz &> /dev/null
if [[ "$?" !...
Use dd to truncate the file, or try a binary editor like hexer to edit and introduce some corruptions.
Example of truncating file using dd
Create 5MB file
# dd if=/dev/zero of=foo bs=1M count=5
5+0 records in
5+0 records out
5242880 bytes (5.2 MB) copied, 0.0243189 s, 216 MB/s
# ls -l foo
-rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo
Truncate 10 ...
Your file is either truncated or corrupted, so xz can't get to the end of the data. tar complains because the archive stops in the middle, which is logical since xz didn't manage to read the whole data.
Run the following commands to check where the problem is:
cat /var/www/bak/db/2017-05-20-1200_mysql.tar.xz >/dev/null
rsync can be used to copy directories, and is capable of restarting the copy from the point at which it terminated if any error causes the rsync to die.
Using rsync's --dry-run option you can see what would be copied without actually copying anything. The --stats and --progress options would also be useful. and --human-readable or -h is easier to read.
Your device has exactly 4294967296 blocks, which is 232, so this smells like a variable-size problem... If you’re running a 32-bit e2fsck, that could explain the error message; the error you’re seeing comes from e2fsck/super.c:
check_super_value(ctx, "blocks_count", ext2fs_blocks_count(sb),
MIN_CHECK, 1, 0);
where check_super_value() is ...
The btrfs Wiki glossary says this about what a generation is:
An internal counter which updates for each transaction. When a metadata block is written (using copy on write), current generation is stored in the block, so that blocks which are too new (and hence possibly inconsistent) can be identified.
Another entry mentions that
Under normal ...
The output is exactly like what you get if you try to list a directory whose x permission bits are missing.
Here's an example on how to reproduce the situation:
$ cd /tmp
$ mkdir dirperms
$ cd dirperms
$ touch foo bar baz
$ mkdir zot
$ cd ..
$ chmod a-x dirperms
$ cd dirperms
bash: cd: dirperms: Permission denied
$ ls -l dirperms
ls: cannot access '...
RAID1 doesn't write any additional integrity data. So it's unable to detect when a disk has silently corrupted data, except via comparing both copies. Even then, it has no way to know which copy (if any) is correct.
RAID1 handles full-disk failure and can correct non-silent data corruption, where the drive signals the error by reporting an unreadable sector ...
It looks like the source filesystem is damaged, typically either due to a kernel bug or to bad RAM (a damaged disk is more likely to result in unreadable files than corrupted data). At this point, all bets are off. However, if the corruption was very localized, it's only that one file's inode that's corrupted, and other files are undamaged, so you can safely ...
ZFS has by default multiple copies of every meta data block. You can enable this feature for data blocks and then have some protection against (localized and non massive) disk errors.
Automatic ZFS Snapshots are also a popular way to protect files against accidental deletion or corruption.
BtrFS can do "RAID1" with a single HDD. Meaning it will put a file twice across the disk. It also stores a checksum of each file, if one file becomes corrupted it can give you the other copy.
Check out their wiki.
If you ran sudo init 6 in the system inside the VirtualBox and that system had corrupted files, then no, init 6 was not the cause of it. There are plenty of other possible causes though, that you may/should investigate.
If you ran sudo init 6 in the host OS, and the system inside VirtualBox had file system corruption, then yes, init 6 was the cause of that. ...
There might still be hope, but your drive seems to have hardware problems (my interpretation of the read error in dmesg output).
You should try to make a copy of what is recoverable from that partition onto another drive (to minimize disc access). Use ddrescue for that, it might take a while but gets most if not all of the recoverable data of the partition.
It is possible in theory: the data+parity gives you three opinions on what the data should be; if two of them are consistent, you can assume the third is the incorrect one and re-write it based on the first two.
Linux RAID6 does not do this. Instead, any time there is a mismatch, the two parity values are assumed to be incorrect and recalculated from the ...
If one could that easily detect when sectors are about to go bad or do go bad, it would likely have been worked into the filesystem by now. Due to the nature of the error, it will often be silent. You need a filesystem that does checksumming. On GNU/Linux BTRFS may be a good bet since I looked online and apparently support was introduced in Debian 6.
Q: Is it possible to format a Kali USB running Live Kali?
If your partitioning tools have problems, you should unmount all partitions,
sudo umount /dev/sdx?
where x is the device letter (for example b, but check that you select the correct letter). The questionmark is a wild card for a character, for example 1, 2, 3, ...
Then you can overwrite ...
After investigation (see the comments in the question), it appeared that the "corrupted" files were in fact empty. This can happen when a downloading program create the entries in the filesystem but fails before having downloaded their content.
To look for them in the current directory and its subdirectories and move them to a directory called trash in your ...
I suggest inspecting the file itself and seeing if it is actually valid and consistent.
cksum computes a CRC. There is a purpose-specific instruction for this on modern x86 CPUs which may or may not be in use here; in that case it is possible that the CPU might be faulty, and also possible that this fault might not show up anywhere else. Consider ensuring ...
You seem to forget to unmount the pen drive before unplugging. The data is being written at hte time when you're physically detaching the drive; this results in a corruption.
In Nautilus, locate the drive in the left panel, click the eject button near its name. Alternatively, find it on the desktop, right-click, choose 'Eject'.
This is the same thing as '...
The first thing to do is make a copy of the file, to make sure it can be read properly e.g to a file called xx.zip, and determine its length:
cp AlineJoseLuisVideoCabina_Folder1.zip xx.zip
ls -l xx.zip
You have the size of any photo from the extracted other zip files, and since you cannot compress photos that much inside a zip file you can calculate if ...