On 12/15/18, Pierre Tempel <pierretem...@gmail.com> wrote: > > First, dot-file actually uses a directory, however, the comments don't seem > to give a reason for this. Why is a directory created, instead of a more > (arguably) traditional lock file (see e.g. git)? dotlockLock creates the > directory with permissions set to 777. As far as I can tell, this could > create a situation where the temporary locking directory is more accessible > than the database file or the db parent directory. Is there a reason the > existing permissions aren't inherited? I suspect this is done to prevent > any issues while deleting the lock directory.
IIRC, this is because creating a directory is an atomic operation on NFS, but creating a file is not. > > Lastly, it seems that all lock types are promoted to EXCLUSIVE with this > strategy. I wonder if that can be changed to allow all previous lock types, > maybe using lock *files* and judging the lock type by content or file name? > In my mind, this would create a completely portable, file-based locking > strategy that doesn't depend on OS-provided locking mechanisms. But I'm > probably overlooking something here, so please correct me if I'm wrong. > No. Unfortunately, if all you have is the presence or absence of a directory to determine if the file is locked, then that is only one bit of information. And there is no way to encode all the other locking states in a single bit. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
