Tag Info

Hot answers tagged

16

There are no guarantees. A Journaling File System is more resilient and is less prone to corruption, but not immune. All a journal is is a list of operations which have recently been done to the file system. The crucial part is that the journal entry is made before the operations take place. Most operations have multiple steps. Deleting a file, for example ...


11

If you know at some point in time the file is good, you can make a checksum of it and use it to compare later to make sure it's still whole. This is useful before transferring files between mediums or across networks. If you don't know about the good state of a file, no there is no universal way or checking for corruption. Only the specific file format in ...


11

No. The most common type of journaling, called metadata journaling, only protects the integrity of the file system, not of data. This includes xfs, and ext3/ext4 in the default data=ordered mode. If a non-journaling file system suffers a crash, it will be checked using fsck on the next boot. fsck scans every inode on the file system, looking for blocks ...


6

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


6

A filesystem cannot guarantee the consistency of its filesystem if a power failure occurs, because it does not know what the hardware will do. If a hard drive buffers data for write but tells the OS that it has written the data and does not support the appropriate write barriers, then out-of-order writes can occur where an earlier write has not hit the ...


5

What you should try is the following: Use file command on the archive to see if it's recognized as gzip-ped data. Run strace gunzip on the file. This will print the last bytes read from the file which might help you identify the point in file where corruption occurs. Run a debug build of gunzip under gdb. Try to correct the corrupted section (you have to ...


5

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


4

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


4

No, there aren't any general solutions. The only way to check if a file is corrupt is to try and read it; only software which knows how to read that particular format can do that. What you could do is use file to identify the type of the file, and then use the type to choose an appropriate program to check the file. You could write a script like this: # ...


4

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


3

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


3

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


3

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


3

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


2

This is most likely a sparse file. (if it isn't, start running now!) It doesn't actually occupy all this space, it has holes. Maybe one large hole. Delete it from the rsync target side, then add the -S (sparse) option to rsync to make sure it recognises and deals with sparse files. The target filesystem type should support sparse files too. (short version: ...


2

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. http://blogs.oracle.com/bill/entry/ditto_blocks_the_amazing_tape Automatic ZFS Snapshots are also a popular way to protect files against accidental deletion or corruption.


2

There are two things to think about here, as hinted at by other answers. The first is File System Corruption. This relates to the meta-data structures that makes the file system usable, and is understood and controlled by the Kernel. The second is the content of the files. When the content of a file is corrupted, the kernel will not know (or care). ...


2

Looks like the inode information for the ostani dir is corrupted. However, the actual data might be just fine. If so, you can use debugfs to recover this. Unmount the hard drive and proceed. debugfs -c /dev/sdNP # replace N and P with the hard disk letter and partition # the -c option opens the filesystem in read-only mode ...


1

iconv -f utf8 -t latin1 should fix it. For example: echo 'C3 83 C2 B3' | xxd -p -r ; echo # ³ is C2 B3; suspect typo in your question ó # confirms xxd -p -r works echo 'C3 83 C2 B3' | xxd -p -r | iconv -f utf8 -t latin1 ; echo ó ...


1

Data corruption? Most likely no. Data loss? possibly. The data that would be at risk when the system loses power during a suspend would be the only things at risk. This data is the "snapshot" of the system's memory that's been temporarily written to disk when you put the system into "suspend" mode. No harm should ever come to your HDD or the data that's ...


1

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


1

In my experience, hard disks that start showing problems have a few hours of (somewhat) useful life left. Turn it off, get a replacement and pray to assorted $DEITIES that the data can be saved. I haven't had hand-on experience with failing memory sticks, but the discussions I've seen point in the same direction: If it starts showing problems, it is drawing ...


1

If you cannot get anything recovered and you just want to try to put it back into a usuable state, follow the dd advice from Renan. If this is your first time doing this, you will need more details. This will delete everything, so be warned. Unplug all other drives and reboot your computer with a Live Linux disk or risk data loss on a plugged in drive. ...


1

If you happen to use ZFS, either you can read the file and it is guaranteed not being corrupted or you got a read error and it is. Edit After the wise comments, here is a clarification of my answer: ZFS can protect and detect against silent data corruption. eg: http://www.zdnet.com/blog/storage/data-corruption-is-worse-than-you-know/191 Of course if the ...


1

The answer is in most cases no: As already mikel said, most journaling file systems can only protect file metadata (information like the name of a file, its size, its permissions, etc.), not file data (the file's contents). This is happening because protecting file data results in a very slow (in practice useless) file system. Since the journal is also a ...


1

ZFS, which is close but not exactly a journaling filesystem, is guaranteeing by design against corruption after a power failure. It doesn't matter if an ongoing write is interrupted in the middle as in such case, its checksum will be certainly incorrect so the block will be ignored. As the file system is copy on write, the previous correct data (or ...



Only top voted, non community-wiki answers of a minimum length are eligible