[SOLVED] Extracting file information from Inode number
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I was wondering if there is any way by which we can extract the file information from inode number, like permissions,ownership,mtime etc. Forexample if i have an inode number such as 4462, then how do i read this inode number to know what all information it has.
Note: it is STRONGLY recommended that this only be used on a dismounted filesystem. It may even require that before it will run.
There is no danger in running debugfs in its default read-only mode on a mounted filesystem. You do have to be aware that information about currently open or very recently modified files might not be up to date. And, debugfs is quite happy to let you shoot yourself in the foot by running in read/write mode and making changes to a currently mounted filesystem. As the manpage says, "debugfs is a debugging tool. It has rough edges!"
Useful for doing chmod on a directory otherwise inaccessible because it is the mount point for another filesystem that you cannot unmount to do chmod conventionally.
You don't need to use debugging tools for that. You can use a "bind mount" to look at parts of a filesystem that are hidden under an active mount point. For example, I have a separate partition mounted on /var:
# df /var
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda6 33032196 5738480 25615732 19% /var
If I want to see what, if anything, is in the root filesystem's /var directory hidden under that mount:
I appreciate all your responses, but I think my question has been little misunderstood. I know how to find and see Inode number what i wanted to know is how i can know file information just by looking at the inode number. I mean i have reading this since i started learning linux that inode number contains 6-7 types of information it few to name like file permissions, information about file owner and when file was accessed/modified. So is it possible if i have a inode number and by just looking at it i can determine file infomation.
I THINK the op wants something like an "openi", which opens a file by the inode number; or a "stati", which would retrieve metadata based on the inode number.
These don't exist in Linux, partly for security reasons, partly because they don't provide any real advantage.
Security wise - it totally breaks GRS which only protects pathnames. It can also bypass user protection - if a user has 700 access mode on his home directory, but files within have 755 (happens a lot), then opening a file by inode bypasses the protection offered by the home directory.
Usefulness - The only system I've seen these system calls was UNICOS... and they were specifically implemented to optimize NFS access. In UNICOS the nfsd services for file access ran in user mode, as the owner of the file (nfsd had additional multi-level security definitions that prevented that user from causing a DOS by aborting the daemons). Since NFS file access is via "handles" which didn't carry file names (a SLOW way to access a file to read a block) - these handles used an inode cached as part of the local handle. Using openi and stati was used to bypass the relatively slow namei lookup in the kernel. Sinc nfsd runs in user mode, it had no choice other than to have a special purpose system call for fast access.
Linux has the NFS servers running in kernel mode to eliminate the DOS possibility. This also means the nfsd task has access to inode lookups without having to go through a namei lookup. So these calls don't provide any real benefit.