On Wed, Sep 26, 2012 at 01:55:33PM +0100, Simon Slavin scratched on the wall:
> There are problems with doing this under some versions of Unix/Linux, > and especially variants like Android. This technique is almost as old as Unix itself. If some OS versions can't deal with it, they're buggy. I would not consider it a "trick", but rather a standard best-practice for dealing with temp files. > For instance, another user/app can make a file with the same name. And how, exactly, would keeping the file around fix this? If the file is properly unlinked, it doesn't exist in the directory. It has no name, so it is impossible to create another file with the "same" name. Besides, if the you kept the file around, you'd have the exact same problem. There are also APIs to get unique temp file names. If an application isn't using them, its buggy. SQLite also uses the string "etilqs" in temp files to avoid collisions. > Or the system may crash while the file is still open. That's why file systems fsck when they remount. There are all kinds of things that can go wrong with a file system when a machine crashes. An application crash is no big deal, however. > I would believe that any Unix user who knows to look in /tmp could > deal with what they found there. No offense to the professional system administrators out there, but I think you're vastly over estimating the average sys-admin, especially when they're a teenager with a new MacBook and just enough knowledge of Unix to be dangerous. Richard made a post about it some months ago. SQLite is embedded in a lot of applications. Some of them are buggy, crashy applications. The reason SQLite uses "etilqs" rather than "sqlite" in the temp file names (as it used to) is because of such clueless people using bad software find the temp files and then go off ranting about how SQLite sucks and needs to be fixed. Flipping the name around weeds out enough Google searches to avoid such people. Of course, emails like this, that use the string, don't help the situation. PLEASE NOTE: if you found this message via a Google search at some future date, please re-read the previous paragraph until you understand the full ramifications of what it is saying. Don't be clueless. > I would say that the file should be deleted normally when SQLite is > finished with it rather than this trick being used. > > Of course, there may be a specific reason why the programmers of > SQLite decided to do this. Because it is the standard, time-tested way of doing this kind of thing on Unix-- for a lot of very good reasons. The file cannot be open by another process, period. Even a root process. So it provides security and isolation from stupid programs doing dumb things. It avoids file name collisions, as the file doesn't exist in the file tree. Deleting the file means that as soon as that SQLite process exits-- no matter how or why-- the file will be cleaned up and removed. That's important for files put outside of /tmp. It can be important for files inside /tmp... most systems only clean /tmp on reboot, and that can be months, if not years, on many Unix systems. Some don't clean /tmp at all. The "create and unlink" pattern is so common, many UNIX systems have a tmpfile() or similar library call to do the whole thing... create a unique file in /tmp, open it, unlink it, and return the file pointer. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
