-
Geoff Simmons authored
POSIX requires that a file description is referenced by mmap(2), so the refcount does not reach 0 when the file is deleted while it is still mapped. So POSIX-compliant systems can be expected to retain the mapping after file deletion. Unless the VMOD goes to the trouble of copying the file, the safe way to update it is to delete it, then write a file with the same name with the new contents. A check may happen to run between deletion and the new write. But because of the property mentioned above, this is not a real problem for memory-mapped files. So the VMOD will work according to these rules: - If a check cannot read a file due to ENOENT, it is not an error. (It is an error if the file does not exist on initial read.) In that case, the file is considered unchanged -- the current mapping continues as the cached file contents. - This means that for the VMOD, a deleted file is *not* considered to be in error, provided it could be read initially (that is, it is already mapped). - We set a flag when the file is deleted, so that the condition can be detected. - Users are advised in the docs that the "delete, then write" procedure is the *only* method for updating the file that the VMOD supports. Other methods may work, some of the time, but you do it differently at your own risk. Also, access(2) is not a reliable means to determine if the file can be read and mapped, because if checks permissions against the real UID/GID, whereas open(2) depends on effective UID/GID. So: - checks begin with open(2), then use fstat(2) for the stat check. - Path searches are done by attempting open(2) with the filename on each directory in the path.
ba5ecac5