GNU bug report logs -
#57501
call-with-file-lock does not remove lock file
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57501 in the body.
You can then email your comments to 57501 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#57501
; Package
guix
.
(Wed, 31 Aug 2022 09:59:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ricardo Wurmus <rekado <at> elephly.net>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Wed, 31 Aug 2022 09:59:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
“call-with-file-lock” and “call-with-file-lock/no-wait” create a lock
file but don’t remove the lock file when they exit.
(guix build syscalls) defines these procedures with “dynamic-wind” so
that the lock is always lifted with “unlock-file”. While “unlock-file”
uses the fcntl syscall to remove the lock on the file, the lock file
itself is not deleted.
I think it should be deleted. When the lock file sticks around we may
run into problems due to lock file ownership. For example, imagine a
cron job running as a different user that upgrades the contents of a
user profile. That cron job would leave behind an unlocked lock file
owned by that user, preventing the owner of the profile from operating
on the profile even though the lock has already been lifted with
“unlock-file”.
I propose letting either unlock-file or with-profile-lock delete the
lock file.
--
Ricardo
Reply sent
to
Ludovic Courtès <ludo <at> gnu.org>
:
You have taken responsibility.
(Sun, 12 Feb 2023 00:53:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ricardo Wurmus <rekado <at> elephly.net>
:
bug acknowledged by developer.
(Sun, 12 Feb 2023 00:53:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 57501-done <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus <rekado <at> elephly.net> skribis:
> “call-with-file-lock” and “call-with-file-lock/no-wait” create a lock
> file but don’t remove the lock file when they exit.
>
> (guix build syscalls) defines these procedures with “dynamic-wind” so
> that the lock is always lifted with “unlock-file”. While “unlock-file”
> uses the fcntl syscall to remove the lock on the file, the lock file
> itself is not deleted.
>
> I think it should be deleted. When the lock file sticks around we may
> run into problems due to lock file ownership. For example, imagine a
> cron job running as a different user that upgrades the contents of a
> user profile. That cron job would leave behind an unlocked lock file
> owned by that user, preventing the owner of the profile from operating
> on the profile even though the lock has already been lifted with
> “unlock-file”.
>
> I propose letting either unlock-file or with-profile-lock delete the
> lock file.
Agreed. Done in a68229b9a0f450db622511adfe00ff7307d745d3, thanks!
Ludo’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 12 Mar 2023 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 45 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.