Files in *nix filesystems almost always have an associated inode number. In most cases users seem not to deal very much with those inode numbers, as they use filenames (i.e. a hierarchical pathnames-filename structure) to interact with the file. Hence renaming a filename is frequently happening

mv oldname newname

How would be a renaming (reassigning) from one to another inode number work?

The background is that I want to backup (i.e., and restore/ catalogue) files from my filesystem. At restore I would be happy to see former inode #7 to become again the lucky inode #7.

Knowing that the kernel's filesystem handling may abstract the handling of inodes, I assume that sometimes another file is given #7 before the one I wanted to assign it to. In short I expect the decision "dear kernel change inode #12345 to #7" to get into trouble when #7 is already taken. Even though—as comparing with filenames—also filenames are unique and when wanting to rename a file to an already used filename I would go about like this:

mv newname othername
mv oldname newname

By the above I was able to have the file oldfile renamed into newname besides having to deal with previously also renaming the previous newname to othername.

Consequently I am confident a way to change/ influence the inode number might exist. In which case this would answer the question perfectly. In case it is somewhat filesystem dependent, I would most like to know it for ext4.


My negligence let me overlook https://stackoverflow.com/questions/5752822/how-do-i-create-a-file-with-a-specific-inode-number which addresses much of the same question. Being SO and not Unix&Linux I am unsure whether it would not be adequate to leave this question here, or delete it. Yet there being already one answer?

  • curious... why does anyone care about what the inode number is? – Peter May 30 '16 at 13:36

Since 35 years, this option no longer exist. Any decent fs will not give you control over inode numbers.

What you can do is to parse the restoresymtsble from ufsrestore, but it is undocumented and binary.

Star uses the same basic algorithm to track renames and puts the database into star-symtable. This file is a textfile and there is the program star_sym that converts it into a human readable form.

So the best you can get is a translation table from old to new inode numbers.

  • While the fs is mounted I can see some reason why it would be "undecent" to give control over inode numbers. yet I miss to understand or maybe misinterpret the implied "it is bad to change the inode number". why would it be so bad to change an inode number? – humanityANDpeace Aug 29 '15 at 9:42
  • @humanityANDpeace: it's not that it's bad in and of itself. The point is that supporting such an operation would add complexity and limit implementation flexibility (and maybe performance). Nobody's added support for changing inode numbers because it's probably hard, and not useful enough to be worth the extra complexity. If you think you really want this feature, update your question with what you're really trying to do in the first place. There's probably a different approach to the big picture. (XY problem). – Peter Cordes Aug 29 '15 at 16:23
  • There is ufs and it's descendants (e.g. ext*) that derive inode numbers from an array index from a total space that is divided into cylinder groups. If you give control over inode #s to the users, this will reduce performance. There is my wofs and it's descendents (e.g. ZFS) that use gnode structures rather than inode structures. These filesystems use inode numbers that depend on the order of file creation relatively to the creation of the fs. These filesystems could allow to let the user give an inode number hint but there is no interface to do this and this cold cause various other problems. – schily Aug 29 '15 at 17:01

With respect to ext4 the debugfs tool can be used in this way
(adequate precaution should be taken as debugfs can corrupt your fs)

Goal to create a file at inode 77 with the name /lucky77. We assume that inode 77 is yet unused/free/available and as is the filename /lucky77. Further we work offline, on an unmounted fs.

debugfs -w /dev/ext4fsblockdev
debugfs 1.42 (29-Nov-2011)
debugfs:  seti <77>
debugfs:  sif <77> mode 0x81B6
debugfs:  ln <77> luck77
debugfs:  sif <77> links_count 1
debugfs:  quit

In case the inode is already in used additional steps would be needed to first change the inode. In simple cases making a copy of a file will and then deleting the original file will free the filename, as a new inode was used for the copy. Anyway more complex scenarios like hardlinks or inodes of directories or else occur. In those cases more than just a simple coping is needed to free the desired inode.


AFAIK, there's no way to copy an inode to another inode without also copying the file's data.

There's also no API for requesting a new file to have a specific inode number.

So all you can do is cp -a old new && rm old to get a new inode for the file, but you can't choose what it will be. And of course this copies the entire data, so it's slow.

FS-specific dump/restore tools for some filesystems may preserve inode numbers, but most don't. Such tools read/write the block device directly, not through filesystem APIs. XFS: xfsdump/xfsrestore (sometimes) don't preserve inode numbers. (Note dumpe2fs only prints info; the Linux ext2 dump command was just called dump. IDK whether it preserves inode numbers.)

Preserving / controlling inode numbers is not a generally useful thing to do. There's no system call to open a file by inum, or even to find filenames that refer to a given inum (other than walking the whole tree). (FS debug tools like xfs_db can of course get at a file by inum, by reading the block device.)

There are a few cases where inode numbers are used outside the filesystem that owns them directly: NFS uses inode numbers as file handles between the client and server. XFS data-migration uses them to match up data migrated to tape with files on the FS. Apparently this is why you might care about xfsdump/xfsrestore preserving inode numbers.

  • Ufsrestore did never recreate inode numbers, you are mistaken. Its precursor from the 1970s did, but it wrote an unmounted fs. – schily Aug 29 '15 at 9:21
  • @schily: thanks, fixed my answer and added some new stuff. – Peter Cordes Aug 29 '15 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.