all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#57501: call-with-file-lock does not remove lock file
@ 2022-08-31  9:50 Ricardo Wurmus
  2023-02-12  0:52 ` Ludovic Courtès
  0 siblings, 1 reply; 2+ messages in thread
From: Ricardo Wurmus @ 2022-08-31  9:50 UTC (permalink / raw)
  To: 57501

“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




^ permalink raw reply	[flat|nested] 2+ messages in thread

* bug#57501: call-with-file-lock does not remove lock file
  2022-08-31  9:50 bug#57501: call-with-file-lock does not remove lock file Ricardo Wurmus
@ 2023-02-12  0:52 ` Ludovic Courtès
  0 siblings, 0 replies; 2+ messages in thread
From: Ludovic Courtès @ 2023-02-12  0:52 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: 57501-done

Ricardo Wurmus <rekado@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’.




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-02-12  0:53 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-31  9:50 bug#57501: call-with-file-lock does not remove lock file Ricardo Wurmus
2023-02-12  0:52 ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.