Hacker News Reader

Comment by prlin | Hacker News Reader

re: 1) any way to use a (named) pipe to replace a directory besides flattening out the dir?

I wouldn't say so: any pipe only allows strictly linear FIFO data transfer, but anything you could call "directory-like" surely allows random access - at least jumping to the start of any of the contained files.

I think, if you wanted a truly self-tidying temporary directory... you might be able to mkdtemp(), immediately chdir() into it then unlink() it, and thereafter work on the files within by relative paths only - as the directory's link count would be zero, it should get automatically cleaned up when the process exits. (Well, unless your program gets killed between the mkdtemp() and rmdir(), of course.)

... alternatively, you might also be able to mkdtemp(), opendir() then rmdir() it, then work on the files in it with openat() & friends. I can't see that being viable in shell scripts, though - too little support for dirfd-relative file operations.

Not sure if either idea would actually be allowed in practice, mind - I haven't tested them, either might fail at the rmdir() stage with EBUSY.

You can only rmdir an empty directory and then after that it's gone and can't have files created in it.

Provided you didn't need concurrent access, what you could do is create a temp file, unlink it, then treat the contents of the now-anonymous temp file as e.g. a zip file or a tar file or similar. But that strikes me as one of those "time to rethink the life choices that led you to this moment" situations rather than a remotely good idea.

I actually tried this idea when I read their initial comment. Unfortunately (And this is obvious when you realize it) you can't `unlink` or `rmdir` a non-empty directory. Also, though `rmdir` can work while you still have an open reference to the directory, once you do a `rmdir` you are not allowed to add any new files to the directory, making it essentially useless.

I think the best way would just to make sure you mount a `tmpfs` somewhere and make a directory on that (With something like your PID in the name). Then have some supervisor program periodically remove all directories with PIDs that are not longer running (Along with having the programs themselves clean it up if they have the opportunity). That's probably the best you can get, I don't think there's anyway to make the directory get automatically cleaned-up by the kernel.

> once you do a `rmdir` you are not allowed to add any new files to the directory

Ah, go figure. I had a feeling you'd run into something like that.

As for your tmpfs idea... you could do something with autofs to get automatic cleanup.

Yeah, it's unfortunate, it'd be pretty cool if you could pull something off like that. And conceptually it's not much different then what you can do with files already.

And autofs sounds like it could do it. I think the simplest implementation wouldn't be very complicated though, you could probably do it with a bash script that cross-checks folder names with running processes every 5 minutes or so. Assuming most programs clean-up after themselves, it only needs to handle programs that do an abnormal exit like SIGKILL. Of course, if that script has problems you'd be in for a bad time.

Reply on news.ycombinator.com