On Thu, Mar 06, 2025 at 10:28:09AM +0100, David Hildenbrand wrote:
On 28.02.25 17:54, Brendan Jackman wrote:
Some filesystems don't support funtract()ing unlinked files. They return ENOENT. In that case, skip the test.
That's not documented in the man page, so is this a bug of these filesystems?
Um...
unlink(2) does say:
If the name was the last link to a file but any processes still have the file open, the file will remain in existence until the last file descriptor referring to it is closed.
And POSIX says
If one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file are closed
I didn't call it a bug in the commit message because my impression was always that filesystem semantics are broadly determined by vibes. But looking at the above I do feel more confident that the "unlink isn't delete" thing is actually a pretty solid expectation.
What are examples for these weird filesystems?
My experience of the issue is with 9pfs. broonie reported on #mm that NFS can display similar issues but I haven't hit it myself.
As we have the fstype available, we could instead simply reject more filesystems earlier. See fs_is_unknown().
Oh. I didn't know this was so easy, I thought that checking the filesystem type would require some awful walk to find the mountpoint and join it against the mount list. (Now I think about it, I should have recorded this rationale in the commit message, so you could easily see my bogus reasoning).
If there's a syscall to just say "what FS is this file on please?" we should just do that and explicitly denylist the systems that are known to have issues. I will just do 9pfs for now. Maybe we can log warning if the error shows up on systems that aren't listed, then if someone does run into it on NFS they should get a strong clue about what the problem is.
Thanks!