Because using a RAM-backed temporary fs is a dumb idea. If your disk caching is implemented properly, then most temporary files are stored in RAM, but larger ones can be spilled to disk, and the OS gets to decide what's best based on a global view of the system. By using a RAM-backed tmpfs you are forced to use RAM and spill to a swap partition that is inflexible and hard/impossible to resize.
Well, it's not only larger files that spill to disk; using a normal directory forces the OS to write them all to disk (even if with a delay thanks to buffers).
A RAM-backed tmpfs, on the other hand, would avoid writing to disk if the size of your files doesn't cross the threshold of free memory.
This is incorrect. Linux doesn't write small files to disk if they are deleted within a certain time. And if that's true for Windows NT, then it's a problem with Windows.
Windows definitely has this "problem". I used to have %TEMP% on my SSD until I realised that VS builds were still bound by temp file + object file write bandwidth, so I've put %TEMP% onto a 1.5G ramdisk. It works very nicely.
Seriously? So if you write a key file or something small to disk and immediately pull the plug on your computer, it will be gone? That is incredibly stupid for a file system that people expect to actually write the file when it says it did.
As the reply from icebraining says, if your program doesn't call fsync(2) or fdatasync(2) but still expects the file to be on disk when someone pulls the plug, then your program has a bug, not the OS.
Yes, seriously, unless the software calls fsync(). As a user, you can avoid that by mounting your disks with the 'sync' option, but prepare for your system to become very slow.
When creating a file handle you can usually specify how buffering will work. You can also say that everything should be written immediately. But even then there can be buffering inside the disk and cause you to lose the data. That's not the file system's fault. And sure, get rid of all those caches in between if you don't care about performance. You can do that.
And "write to the file" usually says "write to the file at a point convenient for you". Heck, it's an asynchronous call most of the time anyway so it cannot complete immediately for obvious reasons.
> But even then there can be buffering inside the disk
this, the system accounts for. If you tell the OS to sync data to disk, it has to make sure that the disk committed the data to the durable media.
One aspect of this is: As the disk, as long as it has unwritten cached data in its internal RAM cache, is free to write that data basically in any order, the OS will have to send a write barrier to the disk. Wouldn't this been accounted for by the OS, all filesystems would basically be completely broken on most power outages. Or one would have to flush the disk cache completely on every single and small change, which would severely degrade performance.
This is why we need better application profiling yesterday. Not "I need write to x location" but "I am highly sensitive to read latency in x location, and highly sensitive to available space (append only) in y location." cgroups is the beginning. Eventually, a much-evolved container notion will solve this. I expect embedded and mobile distributions/OSs to follow suit.
If for no other reason: We would probably be surprised and saddened to see how much software abuses the longevity of "temporary" files and being able to persist them across reboots.
I get annoyed for the opposite reason -- I wish it was easier to say to the OS "Take this directory away when this program finishes". You can get so far with atexit, or unlinking early (but that's no good if you want to pass the files on to other programs).
Is there a reason for this? It just seems like it would cause clutter and garbage to pile up for eternity.