O_DIRECTORY|O_TMPFILE [LWN.net]

O_DIRECTORY|O_TMPFILE

Posted Aug 2, 2026 5:37 UTC (Sun) by donald.buczek (subscriber, #112892)
In reply to: O_DIRECTORY|O_TMPFILE by koverstreet
Parent article: Reconsidering O_CREAT|O_DIRECTORY

It'd create others, though: unlinked files are a problem for observability; if you forget to kill something, or a program is doing something unexpected, it makes "where'd my disk space go" into a real game.

Yes, but we already have that with unlinked regular files.

So, as the bcachefs maintainer: I'd be happy to take patches or implement O_DIRECTORY|O_TMPFILE in bcachefs - after we have a solution to that one.

Would anyone other than you be able to do that? There is no point even asking my employer to release me from work for the last few years leading up to retirement. :-)

You'd need the VFS to track when the tree has gone away, and the dcache would have to be able to operate on disconnected subtrees.

So I think an implementation for tmpfs, which already has its own independent value, would indeed be a good first target and an implementation on a persistent filesystem might come after that.

to post comments

O_DIRECTORY|O_TMPFILE

Posted Aug 2, 2026 7:33 UTC (Sun) by koverstreet (subscriber, #4296) [Link]

> Would anyone other than you be able to do that? There is no point even asking my employer to release me from work for the last few years leading up to retirement. :-)

Your estimate is a couple years for figuring out an API for tracking and viewing unlinked-but-open files? Yeesh.

I get pretty scathing when people pile on complexity without thinking about how it'll be debugged. There's too many opaque black boxes already in the kernel.

My rule is, before you pile something on, you need to make sure what you already have is understandable.