site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Mar 17, 2006, at 1:54 PM, Ron Aldrich wrote: -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Is it legal for a filesystem's blockmap vnode operation to be called for a file which hasn't been opened? I'm working on some optimizations, and need to know whether I should return an error in this case, or just handle it silently. If your FS has vended a vp, then your FS must honor operations on that vp until the vp has been vrele's (the vended vp reference is returned to the FS normally) or the vp has been deadfs'ed (e.g. by a forced unmount or other operation, in which case it's not your FS's vnode any more). Some FS's like to pretend that this isn't an issue for them, and that the FS's idea of "open" and the VFS layer's idea of open must somehow be congruent. An example of this is SMB client, which likes to have the file "open" on the server in order to be able to read it. In the case of execve(), we use namei() to get the FS to vend a vp for a path, and then explicitly map/read pages out of the vp, without ever implementing a formal open notification to the FS. There are several good reasons for permitting this type of access; in particular, for intermittent access, the open/close operations can be implied. This allows an FS that's handicapped (e.g. like SMB, which is incapable of deleting an open file) to more closely echo the expected UNIX FS semantics. The alternative to this would be to return ETXTBSY (for example) on executable files on FS's where the operations could not be accomplished - IFF the FS was notifid that an executing file was in fact "open" from the FS's perspective. This is problematic, since it would mean that some FS's would exhibit the error code, while other FS's would not exhibit the error code. To accomplish this, there would have to be a specific way of internally marking a vnode. Further, this would constitute a KPI change, since it's impossible to update existing programs that expect to be able to delete/rename open files. Even more problematic is that updates of running systems could no longer be accomplished, if this was made a requirement, or made universal to all FS's by implementing it without a KPI change at the VFS layer (consider trying to update "tar" while you are using "tar" to extract the new "tar" from a tar archive, or attempting to update "launchd" without killing "launchd" and effectively shutting down the OS to do it, etc.). The inability to rename/replace/delete running programs is one of the reasons why installing software on Windows requires a system reboot, and why, if you hit <esc> to get the text console, instead of things being hidden behind the splash screen, you see autoexec.bat effectively running a postinstall script in single user mode before the system comes back up (.bat files are tokenized into memory by command.com, so they are immune from this requirement: they are treated as cached data). So in general, you will want to honor all vnop requests on vnodes vended by your FS implementation to avoid behaving differently from other FS's, or damaging the expected UNIX FS semantics, except where absolutely necessary due to FS design limitations. This email sent to site_archiver@lists.apple.com