| Subject: | The unlock method deletes the lock file even when the Lock object has been unlocked |
| Date: | Tue, 16 Apr 2013 10:04:03 +0200 |
| To: | bug-File-NFSLock [...] rt.cpan.org |
| From: | Yann Rouillard <yann.rouillard [...] jouy.inra.fr> |
Hi,
We noticed a little bug in the NFS::Lock module: the module tries to
remove the lock file each time you call unlock even if the lock has
already been previously unlocked.
This can be a problem especially when the lock object is destroyed as
the DESTROY method calls the unlock method.
The problem lies here:
sub unlock ($) {
my $self = shift;
if (!$self->{unlocked}) {
unlink( $self->{rand_file} ) if -e $self->{rand_file};
if( $self->{lock_type} & LOCK_SH ){
return $self->do_unlock_shared;
}else{
return $self->do_unlock;
}
$self->{unlocked} = 1;
[...]
The line "self->{unlocked} =1" is never reached because of the return
statements, so the lock is never properly registered as unlocked.
I would propose the following patch but:
- I don't know if should be better to always internally unlock even
if the file deletion failed (I don't think so but I might be wrong),
- I didn't dig into the signal part at the end to see if it could
have side effect as this code was currently never reached.
So that might not be the best solution.
--- NFSLock.pm 2013-02-15 23:42:27.000000000 +0100
+++ NFSLock.pm.new 2013-04-16 09:54:21.000000000 +0200
@@ -272,11 +272,13 @@
my $self = shift;
if (!$self->{unlocked}) {
unlink( $self->{rand_file} ) if -e $self->{rand_file};
+ my $success;
if( $self->{lock_type} & LOCK_SH ){
- return $self->do_unlock_shared;
+ $success = $self->do_unlock_shared;
}else{
- return $self->do_unlock;
+ $success = $self->do_unlock;
}
+ return 0 if not $success;
$self->{unlocked} = 1;
foreach my $signal (@CATCH_SIGS) {
if ($SIG{$signal} &&
Here are some relevant information about the configuration:
File::NFSLock : 1.21
Red Hat Enterprise Linux Server release 5.6 (Tikanga)
Perl, v5.8.8 built for x86_64-linux-thread-multi
Best regards,
Yann