lock/backup files

[Werner Koch]

On Wed, 17 Oct 2012 02:12, dougb at dougbarton.us said:

> First, the backup files are different in Unix and Windows, filename~ on
> the former, and filename.bak on the latter. So far I haven't run into

Old versions of the FAT file system don't support more than one dot in a
name or the tilde character.  Thus we we had to resort to the ".bak"
suffix.  I think this is not a problem with newer FAT systems or NTFS,
we are a bit conservative here.  Given that this is only for failures
during file updates, I don't think it is justified to add another option.

> no .lock files, and I run Linux, everything works fine. Then if I boot
> Windows it seems to create .lock files for every file, whether I'm using
> it or not, and they remain after I restart. If I then attempt to use gpg
> in Linux I get an error about the lock file being the wrong size.

Recent versions of GnuPG use a more smart locking strategy than old
versions.  The locking does now work on all kind of file systems, even
those which don't support hard links (e.g. EMC servers).  This works for
both, Windows and Unix.  However, multiboot is problematic because we
can't detect that at runtime.  Thus you will always run into problems.
For details see gnupg/common/dotlock.c .

Your problem with the invalid size of the lock file could be solved to
write dummy values into the file under Windows.  However, you will run
into more problems later.

Thus I believe it is better to run a cleanup script at boot time.
Actually it is expected that all files with a prefix of ".#" will be
deleted form time to time (they might be left over after a crash).
Removing all files with a ".lock" suffix in the GnuPG home directory,
after a multiboot switch (assuming it is not a shared directory) is all
you need.  We will never use files with a ".lock" suffix in those
directories to store permanent data.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.