-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
unmerge 3410
thanks
# 3410 is a different bug, requesting that the lockfile be
# cleaned up on process kill
Ian Jackson wrote:
> tags 2531 - patch
> thanks
>
> Nathanael Nerode writes ("PATCH: Make install-info use fcntl (via perl's
> flock) for locking"):
>> This patch converts install-info to use perl's flock for locking.
> ...
>> As part of this change, it now operates directly on the dir file
>
> Unfortunately, this is wrong. If you operate directly on the dir file
> then disk full and other errors can cause the file to be truncated.
> This is OK if you write the new version to a temp file and rename into
> place, because only the temp file is damaged. If you try to do it by
> writing to the primary file directly then if your script fails and the
> primary file is damaged, the next run will probablu overwrite the
> backup.
>
> For this reason, when using fcntl locking, you generally have to use a
> _separate_ lockfile.
Hmm. In that case, what is the *point* of using fcntl locking? *EVER*?
Fcntl locking is a fscking waste of time and effort in this case.
Is it simply to make sure that the lock file is deleted if the program
dies? This can be done in a much simpler way, without a lock-method
transition, by catching kill signals and deleting the lock file on all
exit paths. As suggested in bug 3410, which was mistakenly merged with
this one.
I see absolutely no other advantage to using fcntl locking; none at all.
Therefore I strongly advise closing the bug immediately as "wontfix".
You're the submitter, so I advise that you do.
> Also, when changing between different locking methods, you have to
> either be sure that only your program might be editing the file,
Done. If the lockfile exists, my program dies immediately, before
touching the file. Yes, simplistic, but two versions of install-info
*shouldn't* be running at the same time thanks to the non-parallelism of
dpkg in general, so this is strictly a corner case. As is this entire
bug, until dpkg becomes more parallel.
Of course, the long-term solution is to regenerate the dir file fresh
from sources each time, in which case it doesn't matter whether it gets
trashed by one run. Unfortunately this doesn't appear to be quite
possible yet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEi1akRGZ0aC4lkIIRAgVlAJ48NtlZ6Q9+7oyOk/9Mhy92ApA8VwCaAx8H
4AqBnCNjL5LYsaEZYxNvNA4=
=2zOM
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
