Re: Classify VNODE SCOPE actions for file operations
Re: Classify VNODE SCOPE actions for file operations
- Subject: Re: Classify VNODE SCOPE actions for file operations
- From: Ken Hornstein <email@hidden>
- Date: Thu, 07 Apr 2011 15:25:29 -0400
>I think this discussion is probably moot anyway because even if you get
>a name, you can't depend on using it to find a vnode again (consider
>renaming, deleting, etc).
>You could use it for logging purposes I suppose.
Well, if you wanted to make a kauth decision based on the name (which I
admit is a bit weird to me, but hey, whatever), then you could use it
at that time. The original poster wasn't exactly specific on what they
were interested in doing.
>True for KAUTH_VNODE_ADD_FILE - you have different combos of vnodes
>depending on the real operation. The vfs may not be trying to create a
>file at all - see access1, rename.
I guess it really should be labelled "ADD_FILE_TO_DIRECTORY".
>I don't know about all filesystems, but HFS, Apple's SMB , Thursby's
>CIFS vfs return it.
>NFS doesn't, but I would bet that AFP does. I know va_name is used by
>coreservicesd, and is how FSGetCatalogInfo calls get the name.
Sure, but getattrlist_internal() will simply use vnode_getname() if the
underlying VNOP_GETATTR() doesn't return anything for va_name. My point
is that you can't rely on it; I guess to be portable, you should try
seeing if the filesystem returns va_name and if it doesn't then you
should fall back on vnode_getname(). Although from private conversatons
I've had with Apple people, they hinted that vnode_getname() was actually
pretty reliable.
--Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden