> On FreeBSD, this occurs because devfs doesn't use the name cache. Two > easy solutions are: > > - Use the name cache in devfs. This would have to be done carefully in > the context of cloning, etc, but should work out. > > - Add a VOP/VFS operation to help figure out a pathname with the help of > the file system, and implement it for devfs. This would avoid having to > deal with cache invalidation issues in devfs.
I would prefer whatever would be a lowest impact uniform (for different FSs) solution. I will start looking into this issue. > I'm not familiar with this issue specifically. Normally these descriptors > point to tty's (unnamed due to devfs issues above) and pipes (no name), > which would generally explain the issues. However, the >my.file case is a > bit concerning. Could you confirm that the file descriptor in that case > is definitely pointed at a vnode? I will do this. I would like to point out ( guess I was not clear the first time). That even if std[in/out/err] is VREG, not VCHR after child process inhereted this descriptor vn_fullpath() does not work. I understand that this sounds fishy, because fd simply points to vnode, but that the impression for now. If one closes a "standard" descriptor then opens a file, it does work, but seems not to survive through inheritance. I will follow-up with more information on this. Maybe, files issue for 0..2 is a just a product of imagination :) > Linux does something a little different in how they maintain references to I am aware that Linux dentry/inode/cache are different, but I was asking this for a simple (selfish) reason. If there is a concesus that d_path() like functionality [in a black-box way i.e. let's forget how it is implemented] would be very helpful, then I think if a patch was made it might be committed before 5.5 is out. In that case, I would try to work on this and/or even ask my colleagues to help with coding/testing. If this is viewed as an obscure feature that will not be included anytime soon, I would remove from my agenda for now. I thank you Robert and everyone else who spent time reading this thread and thinking about this whole issue. Thank you, Igor _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
