Why does replace not take a &Dir for the path to be relative to? I suppose using the directory the file is in isn't a bad default but I want to link the file into a different (sibling) directory (makes it easier to have the temp directory of my app be tmpfs and suchlike).
I'm thinking a new method called "rename" on the TenpFile would be appropriate. Actually on Linux the normal file extension trait could have it too
I can imagine that a reason for it is that it may not be possible to do an atomic rename across different Dir
's. For example when the other directory is on another filesystem or one of the directories is on a virtual filesystem existing only in the wasi runtime and the other is on a real filesystem. If that is indeed the reason for not having this, I have no clue.
I think the reason was just that it didn't occur to me at the time that anyone would want to replace to a different directory.
cap-tempfiles itself could be totally fine replacing to a different directory and just failing dynamically if it's a different filesystem and the atomic rename fails. If someone wants a replace
variant that takes a second directory, that should be easy to add.
I suspect the reason it didn't occur to me that anyone would want that is that all the use cases I know of off the top of my head do the replace in the same directory, and the reason for that may well be that if there is a filesystem boundary between the source and destination, the rename will fail, so most use cases deliberately try to use the same directory.
Even with a fs boundary it can be useful, since the temp file is theoretically not accessable to anyone else (unless you hand them the fd over a pipe or something)
I'll probably cook up an implementation at some point, will probably call it "rename" so replace can be kept if needed. Alternatively I could call it "link"
Often the reason for using a tempfile and then renaming it into place is so that the update is atomic. If the tempfile lives on a different filesystem, there's no way to do an atomic rename. Other processes reading the file could see truncated contents.
Right. I mean rename just doesn't work across filesystems, presumably windows would pass the "don't copy" flag as well.
In my case the reason for using TempFiles like this is that I need to look at the data in the file to figure out what it's final name should be, and cap-tempfile (and like O_TMPFILE generally) just has fewer foot guns than alternatives
Last updated: Nov 22 2024 at 16:03 UTC