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.
I would go about this in a different way - specifically, using a depth-first search in place of the shell globstar **
For example, using GNU find
, given:
$ tree
.
└── dir
├── foo
│ └── baz
│ └── MainFoo.c
└── Foo
├── baz
└── MainFoo.c
5 directories, 2 files
then
find . -depth -iname '*foo*' -execdir rename -- 's/Foo/Bar/;s/foo/bar/' {} +
results in
$ tree
.
└── dir
├── bar
│ └── baz
│ └── MainBar.c
└── Bar
├── baz
└── MainBar.c
5 directories, 2 files
Best Answer
You can rename a file (directory or whatever) using only knowledge of the inode using
find
, but if (a) the filesystem containing it is not mounted, or if (b) there is another filesystem mounted over a non-empty directory that contains the file you are interested in, the file is simply not accessible by your system. In case (a), you need to mount the filesystem before you can do anything to the contents, including renaming, and in case (b), you need to unmount the filesystem which is mounted "over the top of" the directory containing the file you want to rename. It looks like you are asking about case (b).If I understand you correctly, you are trying to make your old
/home
directory (which is located on your root partition) accessible, while still using your new partition mounted at/home
. If that's what you want, do the following:Close all files and log out. Then log in as
root
(use a virtual terminal for this—press Ctrl-Alt-F2) Run the following:If all is well, log out and log back in as yourself and all should be fine.
Incidentally, the command to rename a file using only knowledge of its inode (assuming the file is in the current directory) is:
Where
123456789
is the inode number, of course. (Note thatfind
determines the filename and its path and passes this info tomv
; there is no way at all to rename a file without involving the existing filename in any way, but if it's just that you don't know the filename, it is quite simple.)