Re: mdconfig feature request

From: Tobias Roth <roth_at_iam.unibe.ch>
Date: Thu, 7 Aug 2003 13:20:35 +0200
On Wed, Aug 06, 2003 at 10:21:36PM -0700, Terry Lambert wrote:
> Tobias Roth wrote:
> > would it be possible to add the currently attached vnode (or the
> > complete path to it) to the output of
> > 
> >   mdconfig -l -u <devicenumber>
> > 
> > that would simplify some things for me.
> 
> You could do the vnode.  Doing the path is hard.

the vnode is good enough for me. would someone be so kind to implement
that?

or will this still cause problems because the vnode file can actually
be deleted (as stated below)?

> The kernel doesn't really know from paths.
> 
> Basically, the path is not known to the kernel; it's thrown away
> as soon as it's translated to a vnode, because it's pretty much
> useless wasted space, as far as the kernel is concerned, and the
> only reason it deals with them at all is because it has to deal
> with humans.
> 
> The actual problem is that while there was *a* path to a file, it
> may not be *the* path to the file, and it *may* have included
> symbolic links, and it *may* have been one of several hard links
> (how do you know which one to return, especially if you are using
> exclusion groups or directory permissions to hide information?),
> and it *may* be that the file was subsequently deleted, and the
> only thing holding it in existance at all is the mdconfig reference
> that's outstanding (in which case, the path would best be described
> as "you, you fool!").
> 
> So, unless you are using an FS that doesn't permit hard links, and
> doesn't permit deleting open files (e.g. a file share from an SMB
> server, like Windows NT 3.5.1 or Windows XP or Windows 2000), you
> are pretty much SOL as to reliably getting the path back from just
> the vnode reference.
> 
> The best thing to do is to remember what you did, so you can tell
> the kernel again later.
> 
> -- Terry
Received on Thu Aug 07 2003 - 02:20:38 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:18 UTC