Greg Wooledge (HE12025-12-23): > If you're using a temp file in a shell script, typically that temp > file is very short-lived. Almost always less than one second.
That is quite an assumption. It is true that most shell scripts are very short-lived, but most shell scripts do not require temporary files either. Requiring a temporary file makes the script atypical in a way that is probably correlated with requiring a long time. > A temp file that's created, written to, read from, and deleted all > within such a short span of time will probably *not* be written to a > physical device. I find that assertion highly dubious and dare you to test it. The obvious way to implement creating and deleting a file in a filesystem would be to make immediately all the manipulation of the data and metadata (finding free blocks, removing them from the free list, writing the data into it) in the memory cache and mark the pages as dirty to schedule their permanent storage. Within that framework, noticing that a file was deleted before the dirty buffers were written and cancelling their write would be a specific optimization. And not an easy one at that: it would require putting everything *back* into place instead of doing a normal delete operation on top of the new state; and that might not even be possible if other files were created or grown in the meantime. And it is an optimization kernel maintainers do not have an incentive to implement as a filesystem with permanent storage is not the right tool for extremely-short-lived files. Of course, all of it is moot if there is layer of cache and delay between the abstract virtual filesystem maintained by the generic code of the kernel and the actual filesystem. But this is extremely unlikely as the success of write operations can depend on the specifics of the filesystem. > To the OP: please tell us WHAT YOU ARE TRYING TO DO. Specifically. I predict we will never know. Regards, -- Nicolas George
