Tag Info

Hot answers tagged

225

If you run fsck, the filesystem check and repair command, it might find data fragments that are not referenced anywhere in the filesystem. In particular, fsck might find data that looks like a complete file but doesn't have a name on the system — an inode with no corresponding file name. This data is still using up space, but it isn't accessible by any ...


26

The lost+found directory (not Lost+Found) is a construct used by fsck when there is damage to the filesystem (not to the hardware device, but to the fs). Files that would normally be lost because of directory corruption would be linked in that filesystem's lost+found directory by inode number. Some of these might be lost directories or lost files or even ...


9

Why would you ever need to run this command? In case the lost+found directory doesn't exist. Since it's just an ordinary directory, the root user can remove it using rm -r. Some versions of fsck, when they need to make use of a lost+found directory, will create it if it doesn't exist, and some versions won't. If there's no lost+found directory, fsck ...


8

From "Linux Filesystem Hierarchy", section /lost+found": As was explained earlier during the overview of the FSSTND, Linux should always go through a proper shutdown. Sometimes your system might crash or a power failure might take the machine down. Either way, at the next boot, a lengthy filesystem check using fsck will be done. Fsck will go ...


3

Q1. Why would you ever need to run this command? The lost+found directory already exists in / on every distro I've checked. Something needs to create the lost+found, this command would appear to do that. Every medium you mount needs to maintain its own lost+found. excerpt from man page mklost+found is used to create a lost+found directory in the ...


2

"The lost+found directory already exists in / on every distro I've checked." But that's not the point. Every "real" filesystem (which maps to a block storage of some sort, as opposed to pseudo filesystems like /proc and swap) needs a lost+found orphanage. For example, if you have a separate filesystem for /home, then there should be /home/lost+found. ...


1

Try #1: Maybe it is there yet, only its name changed to f.e. /lost+found/#3456254 and like. In your place I did a recursive file -szL for everything in /lost+found, and grepped for innodb: find /lost+found -type f|xargs -P 1 -n 500 file -szL|grep -i innodb If there is an innodb database yet therein, you have your data to save. Good luck! Try #2: If ...


1

It IS possible that the file(s) in question were unable to be reconstructed by fsck that they were deleted. The fsck program only attempts to repair and tries very hard to reconstruct files as well as it can. However, it is by no means any type of backup. Any action that is performed by fsck is basically not reversible. I'd be really careful about ...


1

Each appliance has its own compilation of BusyBox with different sets of features, so I can't be sure what yours supports. If I understand correctly, you have directories like /lost+found/#123456, and every file in that directory belongs to the same user. Here's an untested script that dispatches these directories into the user's home. I assume that your ...



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