On Sat, 18 Jun 2011 09:24:44 +1200, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
While that could be done, you have to take into account that the node -path pair is not just a pair, but each node can have any number of paths. For the problem you are trying to solve, this is not reallyimportant though. Furthermore, a path can change at any time, which makes it quite annoying to keep up.
ah yes missed that, but that should not really be a problem, if the file is renamed before analysed the analyser fails because it can open the file. in this case the server could keep a dirty file list. A file is removed from this list when a B_ENTRY_REMOVED message arrives (the file is really gone) or when a B_ENTRY_MOVED message comes in, in this case the dirty file has to be handled like a modified file.
For a fulltext database it should not be a problem to handle hard links each entry/node could just have multiple path and the db has to check if the node is already there...
But for that particular problem, it's also not needed to go this route. For one, BFS always knows the parent of an inode (as it doesn't support hard links, and needs this feature for queries to work), so it wouldn't be needed to store the data twice in that case, anyway. But since this would only work for BFS, one could also just allow root to open any known node_ref, just like every directory can be opened via a node_ref. The vnode will be in the VFS anyway while the file is open, and even if you're not fast enough, and didn't open it in time, chances are very good that the vnode is still around afterwards. You could even make it 100% reliable with a callback mechanism if needed.
If I get you right, you mean to open a file just by its inode? This would not give me the path, right? In case of a fulltext analyser I need the path though. Otherwise the extracted information is pretty useless.
So in general the node->path hash map value must be a list of paths (node -> list of paths). The paths can be updated in common_rename.
Note that the path information is only duplicated as long as the file is open.
thanks,
Clemens
