@cas was correct in his assumption that "It's simpler for fsck to just create a lost+found directory with more reserved space for found files than to expand it if/when needed. With some types of fs corruption, it may not even be possible or safe to expand the lost+found dir while fsck is fixing errors."
I'm not sure why I didn't before, but if you consult the mklost+found man page it gives you this information:
mklost+found pre-allocates disk blocks to the lost+found directory so
that when e2fsck(8) is being run to recover a filesystem, it does not
need to allocate blocks in the filesystem to store a large number of
unlinked files. This ensures that e2fsck will not have to allocate
data blocks in the filesystem during recovery.
The deeper answer to the specific question, why the file size is 49,152KB (or 49 MiB, or 12 sectors) is somewhere in the files below. It's the reason I was so curious about, but I still haven't found it out (I can't read C very well). If someone has free time, and knows I, and can explain the why, I will accept your answer over this one:
Your description of the process isn't quite right.
The kernel keeps track of which paths are mount points. Exactly how it does that varies between kernel, but typically the information is stored in terms of paths. For example the kernel remembers “/ is this filesystem, /media/cdrom is this filesystem, /proc is this filesystem”, etc. Typically, rather than a table mapping path strings to data structures representing mounted filesystems, the kernel stores tables per directory. The data associated with a directory entry is classically called a dentry. There's a dentry for the root, and in each directory there's a dentry for each file in that directory that the kernel remembers. The dentry contains a pointer to an inode structure, and the inode contains a pointer to the filesystem data structure for the filesystem that the file is on. At a mount point, the associated filesystem is different from the parent dentry's associated filesystem, and there's additional metadata to keep track of the mount point. So in a typical unix kernel architecture, the dentry for / contains a pointer to information about the root filesystem, in addition to a pointer to the inode containing the root directory; the dentry for /proc (assuming that it's a mount point) contains a pointer to information about the proc filesystem, etc. If /media/cdrom is a mount point but not /media, the kernel remembers in the dentry for /media that it isn't allowed to forget about it: remembering about /media isn't just a matter of caching for performance, it's necessary to remember the existence of the mount point /media/cdrom.
For Linux, you can find documentation in the kernel documentation, on this site and elsewhere on the web. Bruce Fields has a good presentation of the topic.
When the kernel is told to access a file, it processes the file name one slash-separated component at a time and looks up the component each time. If it finds a symbolic link, it follows it. If it finds a mount point, no special processing is actually necessary: it's just that the inodes are attached to a different directory.
The process does not use inode numbers, it follows pointers. Inode numbers are a way to give a unique identity to each file on a given filesystem outside of the kernel: on disk, and for applications. There are filesystems that don't have unique inode numbers; filesystem drivers normally try to make up one but that doesn't always work out, especially with network filesystems (e.g. if the server exports a directory tree which contains a mount point, there may be overlap between the set of inodes above and below that mount point). Rows that map name to inode number are the way a typical on-disk filesystem works if it supports hard links; filesystems that don't support hard links don't really need the concept of inode number.
Note that information about mount points is stored only in memory. When you mount a filesystem, this does not modify the directory on top of which the filesystem is mounted. That directory is merely hidden by the root of the mounted filesystem.
Best Answer
You cannot detect or create such files in general. They only exist because a filesystem is reporting inconsistent data.
In the absence of modifications to the filesystem, there are redundancies between various ways of obtaining information about the files on that filesystem. For example, permissions permitting:
readdirthen callinglstaton that name will succeed.lstatdoes not report the file to be a symbolic link, then callingstatandopenwill also succeed.statsucceeds thenopensucceeds`.opensucceeds then so dostatandlstat.statreports a file to be a directory thencdsucceeds and vice versa.And so on. When a Reiserfs filesystem omits the
.reiserfs_priventry from directory listings and yet reports it as a directory via system calls that access it directly, the filesystem is reporting inconsistent information.This information isn't wrong, just inconsistent. It's only violating conventions, not rules. The same behavior could be observed if there was a very fast goblin who created that directory just before you ran
cdorls .reiserfs_priv, and removed it just before you ranfind.It is somewhat bad form for a filesystem to report inconsistent data, because that confuses some applications and users, so it should only be done for a very good reason. In the case of Reiserfs, the reason is to make some information rather hidden, and in particular not traversed by file searches and indexing. This is useful because the content of
.reiserfs_privis not “real” files, it's used to store extended file attributes, which are accessed by calling the*xattrsystem call family. In fact, I don't know why it's exposed at all — maybe only for debugging purposes.Another example of not reporting files that exist is filesystems that allow the same data to be returned in different ways. For example, ciopfs presents a case-insensitive view of a filesystem; if you have a file called
Foothen a directory listing will only listFoobut accessingfoo,FOO, etc. will succeed.