On 18 Nov 2009, at 7:15pm, priimak wrote: > I see. However, the problem is related to journal been named after the > database name. > That should not be a problem if I use symlink to access database for > reads only and > actual db file name for updating, isn't?
If you use a symbolic link for a database file, there's some doubt about where the journal file belongs. The documentation says "The rollback journal is always located in the same directory as the database file and has the same name as the database file except with the 8 characters "-journal" appended." The problem is that there's no way for sqlite to tell that your symbolic link is not the real database file. So it could create the journal file in the directory containing the link rather than the directory containing the actual database. And if another application opens the database directly rather than using the link, it will not find the journal file, so it will not deal with anything needing the journal file correctly. This is mentioned in section 6 of <http://www.sqlite.org/lockingv3.html> If that documentation is right, then for symbolic links, that might be considered a bug in sqlite. It should be possible to do a 'resolve links' on the file specification before deciding where to create the journal. On the other hand, for hard links this is not possible: the hard linking system does not have a 'real' location for the file and other pointers to it, instead each link to the file is equally valid. But either way it is documented that you shouldn't use links. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
