On 26 Sep 2012, at 2:36pm, Clemens Ladisch <clem...@ladisch.de> wrote:
> Simon Slavin wrote: >> On 26 Sep 2012, at 5:42am, Dan Kennedy <danielk1...@gmail.com> wrote: >>> So when SQLite requires a temporary >>> file, it normally creates and opens a file with a randomized name >>> in /tmp then calls unlink() on it immediately - before it starts >>> using the file. >> >> [...] There are problems with doing this under some versions of Unix/ >> Linux, and especially variants like Android. For instance, another >> user/app can make a file with the same name. > > Andorid doesn't have a shared /tmp. In any case, temporary files are > opened with O_CREAT|O_EXCL, so two apps will never accidentally open > each other's file. Furthermore, by deleting the file immediately after > creating it, the time window in which a conflict is possible is made as > short as possible. Allow me to present an alternative point of view. If filling up your filespace is causing you to crash, it's easier to understand what's going on if you can see the files which are filling it up. Running out of disk space when you can't see huge files makes it difficult to debug. With an unlinked file I would find it hard to figure out what was filling my hard disk causing me to crash. Avoiding filename clashes can be done by creating files with random or time-related elements to their names. It's less of a problem. >> Or the system may crash while the file is still open. > > How would a file that clogs up /tmp be preferrable to some unnamed data > that will be automatically removed from the file system by the fsck > after the crash? Unix deletes the contents of /tmp at boot time. That's why it's special. In contrast, using unlink() can cause some chaos including filespace hogs turning up in lost+found -- the sort of thing that might cause problems that a mundane user might never understand. >> Is there any chance that the use of this trick can be discontinued ? > > This is not a trick, it's a widely used Unix idiom. It's widely used outside /tmp. It's an alternative to using /tmp, especially on platforms which don't support a /tmp. I don't think the two techniques are often used with the same file. If you're using /tmp then your sysadmin/programmer needs to know what's suddenly killing freespace on their working volume and looking in /tmp is a great way to find everything that might be a problem. But if the file is unlinked they'll never see it. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
