getting the filename from inode - OS Message Boards

OPERATING SYSTEMS I	COMS W4118, Dept of Computer Science, Columbia University

	Home \| Announcements \| Lectures \| Homeworks \| Grades \| Discussion \| Resources

OS Message Boards

Projects & Assignments

getting the filename from inode

profile | register | preferences | faq | search

UBBFriend: Email This Page to Someone!

next newest topic | next oldest topic

Author	Topic: getting the filename from inode
wc164 Member	posted 12-13-2000 01:05 AM I know how to get to the inode from the filename. But I don't quite understand how to get to the filename from the inode, well, as least to get the directory path, so that I can know which .acl file to open when I try to test for the right permissions since there could be multiple .acl files in different directories. There are no dentry pointers in the inode, only the superblock. Any hints? IP: Logged
natekidwell Administrator	posted 12-13-2000 01:45 AM Basically, you can't get the filename from an inode (there was some discussion about this earlier on the bbs). Therefore, you should just check permissions in places where you know the filename & inode simultaneously, or use that knowledge to manipulate the inode structure for later assessment. Nate quote: Originally posted by wc164: I know how to get to the inode from the filename. But I don't quite understand how to get to the filename from the inode, well, as least to get the directory path, so that I can know which .acl file to open when I try to test for the right permissions since there could be multiple .acl files in different directories. There are no dentry pointers in the inode, only the superblock. Any hints? IP: Logged
molnard Member	posted 12-13-2000 12:49 PM It is not correct to state that the filename is not possible to obtain from an inode. Actually, we wrote code that does exactly that. It is no way simple, though. I do not want to disclose the details (until Thursday) but it is based on navigating the parent links and constructing the pathname based on their name fields. Denes IP: Logged
molnard Member	posted 12-13-2000 03:17 PM Key: actually there is a whole list of dentry pointers in struct inode. My post regarding inode->list_head may give you a hint on how to use them. Denes [This message has been edited by molnard (edited 12-13-2000).] IP: Logged
natekidwell Administrator	posted 12-13-2000 08:32 PM Denes - You're 90% correct, but it's a wierd situation. I assume what you're using is the i_dentry member of struct inode, which is the anchor for the d_alias member of struct dentry. This supposedly keeps track of all the different dentries that refer to the same inode. The problem with this is that for the most part the dcache only contains dentries for files that have been looked up recently. Therefore, you will still not be 1) taking into account a hardlink that exists in some corner of a huge filesystem (what if you're saddled with only 4 megs of ram total and have a 30 gig disk?) if you want to be using all other .acls that exist and 2) risking that if a hardlink has a member in the dcache that is indexed where you'd be expecting to find your inode's dentry you might be using that hardlink's .acl (or lack thereof) to determine permissions. There has been some discussion about d_alias on the kernel mailing lists but they generally advise staying away from it because some filesystems (I don't think ext2, but who knows) use it dangerously. Now there might be a nifty way to use the d_lru list member of struct dentry (even though I think that's for unused entries only) & some form of locking to ensure that the dentry referred to __is__ definitely the one you want. At any rate, the comlexity involved seems beyond the scope of the assignment, but I will definitely check into it further because you've got me thinking now... Maybe some form of locking is already occuring that makes it impossible for one dentry to appear before another inappropriately. That would solve this problem then I guess. But then youd have to guarantee that that locking is preventing another entry from superseeding the desired one at every turn of events. Nate quote: Originally posted by molnard: It is not correct to state that the filename is not possible to obtain from an inode. Actually, we wrote code that does exactly that. It is no way simple, though. I do not want to disclose the details (until Thursday) but it is based on navigating the parent links and constructing the pathname based on their name fields. Denes IP: Logged
molnard Member	posted 12-13-2000 11:41 PM Thanks Nate, I am happy to hear an independent opinion. I cannot say I analyzed all the code in sufficient depth to claim that I can catch all hardlinks. However, whenever you pass a filename to syscalls, it will be looked up and its dentry and its parent's dentry make it to the cache. This alone is enough to look up the .acl file - however this is not what we did (we wanted it badly but somehow lookup_dentry called with a nonzero base messed up the directory cache and we got warnings with d_count == -1). This takes care of the direct(?) link but it is plausible that it may miss some or all hard links in the situation you mentioned. I just ran a find in a different directory tree to flush the cache and confirmed that this indeed happens. The direct link was found, however. On the other hand, storing inodes has its own problem as well - though not hopeless. Because one can delete a file and create one with the same name - which possibly results in a new inode. Hence, the pointers in the .acl file must be updated upon delete and/or create. Also, rename may be so intelligent that it does not create another inode just updates the old one (just a guess, though). This is a very annoying feature if you move files to different directories - since now you have to update the two relevant .acl files, as well. If your move is within the same directory (different filename), not caring about .acl updates gives you the feature that once you have .acl permissions on a file, they "stick" to it. However, if sys_rename does not work (e.g., permission problems or rename is not implemented), the UNIX command move ('mv') actually proceeds with copying the file (we learnt this to our big surprise), in which case one has to hack delete/create to produce exactly the same behavior for consistency. Where is the kernel mailing list you mentioned? I am curious to find out what the linux guys say about their own product. Denes [This message has been edited by molnard (edited 12-14-2000).] IP: Logged
natekidwell Administrator	posted 12-14-2000 11:52 AM send the line "subscribe linux-kernel your_email@your_ISP" in the body of the message to majordomo@vger.kernel.org (don't include the " characters, and of course replace the fake email address with your true address) The list itself is about 10 megs a day of flames, trolls, etc., so a safer bet is to go to the summaries at: http://kt.linuxcare.com/kernel-traffic/latest.epl Cheers, Nate IP: Logged

All times are ET (US)	next newest topic \| next oldest topic
Administrative Options: Close Topic \| Archive/Move \| Delete Topic
	Hop to:

Contact Us | Home

Ultimate Bulletin Board 5.45c