1

Is there any way to find exactly the blocks allocated to a inode, and view that file? I don't care if I have to be on a live cd, but i need to do this for example:

cat verylongsentice > a
ls -i a
101010 a
ln a /some/random/path
rm a
inode_find 101010
verylongsentice

is there any way to do this? maybe as root or from a live cd? I do not care about the file name. Also would this be possible with deleted files?

jp_
  • 27
  • You mean without using find . -xdev -inum 101010? – Stéphane Chazelas Jun 11 '23 at 08:02
  • no. i need to actually open the file by inode. i do not need the file name. – jp_ Jun 11 '23 at 08:06
  • Your requirement is that given an inode, you need to be able to open the file. By using @StéphaneChazelas answer you can do that. Maybe you don't care about the name, but the OS does. What do you care if the implementation involves the name of the file or not, as long as you get your result? – aviro Jun 11 '23 at 08:13
  • 1
  • because find will only look in directory entries. i need to find the file of a inode, even if the file is deleted. also note i can boot into live cd. – jp_ Jun 11 '23 at 08:19
  • 1
    A "deleted file" means that the inode was deleted from the filesystem table, so that's definitely wouldn't be possible (unlss there is still a running process holding a file descriptor to this file). Moreover, there are some FS types that reuse an inode for a new file as soon as inode was released by a deleted file. – aviro Jun 11 '23 at 08:27
  • You could try with debugfs to see what there's left of deleted files. https://man7.org/linux/man-pages/man8/debugfs.8.html – ilkkachu Jun 11 '23 at 09:19
  • 1
    similar question: https://unix.stackexchange.com/questions/92816/can-a-file-be-retrieved-by-its-inode – myrdd Jun 11 '23 at 09:27
  • @myrdd oh I wasn't aware of that QA! Let's try to mark this a duplicate of that, it really is. – Marcus Müller Jun 11 '23 at 10:44

1 Answers1

2

There's no inode number for a deleted files. Also: Inode numbers are not guaranteed to be immutable, or not be reused immediately.

In the comments below your question you're very insistent that what you want should work. It shouldn't:

To open a file directly by inode nr and not through file name is in direct conflict with how the POSIX idea of a file works. It also would be incompatible with the POSIX permissions model, in which the path through which you access a file devices whether you can or cannot access it.

Therefore, the Linux kernel cannot offer you an API for opening files via inode.

In case the file does still exist, AND your file system actually stores inodes (I would guess most file systems do not store actual inode numbers, as that's a bad way to organize a large file system, but a remnant from the 1970s, probably. The file system driver would compute the inode nr from positions in directory tree structures, maybe, or something else), you could go in, and use find /mountpoint -i {number} to look for a file of that inode number on the whole file system. If it has already been deleted, it doesn't exist anymore, and you thus can't find it.

  • i dont care about the kernel api if the drive is not mounted, and the inode has not beenreused, why cant you just open the file? – jp_ Jun 11 '23 at 08:46
  • Because it's not implemented that way, as explained in the answer. If you have a service program (e g. By writing one) for your specific file systems (as also explained, inode numbers are implementation details and not present in the storage format for all file systems to begin with), you certainly could just get the blocks/extents/metadata-stored contents of that file from the raw block device instead of through the Linux file system layer. But that program wouldn't be any more useful than the find approach, and it wouldn't offer the luxury of just opening the found file in any program. – Marcus Müller Jun 11 '23 at 08:51
  • I think you mistyped ”devices“. Also, I'd abbreviate ”number“ in uppercase (No or Nr). – myrdd Jun 11 '23 at 09:17