Steve French wrote on Thu, Oct 21, 2021 at 06:15:49PM -0500: > Have changes been made to O_TMPFILE? It is problematic for network filesystems > because it is not an atomic operation, and would be great if it were possible > to create a tmpfile and open it atomically (at the file system level). > > Currently it results in creating a tmpfile (which results in > opencreate then close) > immediately followed by reopening the tmpfile which is somewhat counter to > the whole idea of a tmpfile (ie that it is deleted when closed) since > the syscall results > in two opens ie open(create)/close/open/close That depends on the filesystem, e.g. 9p open returns the opened fid so our semantic could be closer to that of a local filesystem (could because I didn't test recently and don't recall how it was handled, I think it was fixed as I remember it being a problem at some point...) The main problem with network filesystem and "open closed files" is: what should the server do if the client disconnects? Will the client come back and try to access that file again? Did the client crash completely and should the file be deleted? The server has no way of knowing. It's the same logic as unlinking an open file, leading to all sort of "silly renames" that are most famous for nfs (.nfsxxxx files that the servers have been taught to just delete if they haven't been accessed for long enough...) I'm not sure we can have a generic solution for that unfortunately... (9P is "easy" enough in that the linux client does not attempt to reconnect ever if the connection has been lost, so we can just really unlink the file and the server will delete it when the client disconnects... But if we were to implement a reconnect eventually (I know of an existing port that does) then this solution is no longer acceptable) -- Dominique Martinet | Asmadeus
