Intrepid has asked for the wisdom of the Perl Monks concerning the following question:

Hello good monks and nuns. I'm in the build directory for the distribution File::NFSLock working on installing it as I'm doing with hundreds of modules I've made a bundle of on one machine, getting them put in place on a new machine (finally figured out how that works). The tests in File-NFSLock stagger to a halt, freezing up in the code shown below, which is in t/120_single.t

Is it possible that the lock operations are breaking because I have the build directories for these modules on a FAT32 filesystem, rather than NTFS? Wild guess.

# Blocking Exclusive test within a single process (no fork)

use Test::More tests => 2;
use File::NFSLock;
use Fcntl qw(O_CREAT O_RDWR O_RDONLY O_TRUNC LOCK_EX);
use File::Temp qw(tempfile);

my $datafile = (tempfile 'XXXXXXXXXX')[1];

# Create a blank file
sysopen ( my $fh, $datafile, O_CREAT | O_RDWR | O_TRUNC );
close ($fh);
ok (-e $datafile && !-s _);
# Wipe any old stale locks
unlink "$datafile$File::NFSLock::LOCK_EXTENSION";

# Single process trying to count to $n
my $n = 20;

for (my $i = 0; $i < $n ; $i++) {  # <-- we never see output after thi
+s point in the code (Soren)
  my $lock = new File::NFSLock {
    file => $datafile,
    lock_type => LOCK_EX,
  };
  sysopen(my $fh, $datafile, O_RDWR);

  # Read the current value
  my $count = <$fh>;
  # Increment it
  $count ++;

  # And put it back
  seek ($fh,0,0);
  print $fh "$count\n";
  close $fh;
}

# Load up whatever the file says now
sysopen($fh, $datafile, O_RDONLY);
$_ = <$fh>;
close $fh;
chomp;
# It should be the same as the number of times it looped
is $n, $_;

# Wipe the temporary file
unlink $datafile;

[download]

I'm using CygPerl v5.40.3 (5.040003), on Windows 11. I am testing File::NFSLock 1.29. Do any of my good friends in the Cygwin camp here at Perlmonks get the same result? I checked RT @ cpan.org and didn't see any tickets that would apply to what's happening.

    — Soren

EDIT

I ran a test on my first system, that is, the one that the mentioned Bundle:: file came from; it's also Windows 11. The same CygPerl version. Guess what the result was ... yeah, the tests all passed. I have a significant amount to think about from the two (right now) replies below (thanks guys). But before immersion in NFS lore I thought I'd just try that. I have no theories at the moment. I will note, Alexander, that I don't recall ever choosing to install File::NFSLock on my computer. I think something I knowingly meant to install had a dependency on it.

Jan 18, 2026 at 22:04 UTC

A just machine to make big decisions
Programmed by fellows (and gals) with compassion and vision
We'll be clean when their work is done
We'll be eternally free yes, and eternally young
Donald Fagen —> I.G.Y.
(Slightly modified for inclusiveness)

Replies are listed 'Best First'.
Re: Is getting locks on files with NFS broken on CygPerl?
by choroba (Cardinal) on Jan 17, 2026 at 20:08 UTC
    The model's Synopsis shows: 
    if (my $lock = new File::NFSLock {
...
}else{
  die "I couldn't lock the file [$File::NFSLock::errstr]";
}

    [download]

    Where do you check that $lock is true? Try adding a similar check.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
[select]
Re: Is getting locks on files with NFS broken on CygPerl?
by afoken (Chancellor) on Jan 18, 2026 at 01:28 UTC
    I'm using CygPerl v5.40.3 (5.040003), on Windows 11. I am testing File::NFSLock 1.29.

    NFS is a Unix thing. Are you sure Win11 does support NFS? Out of the box?

    Answering my questions: Yes, it does support NFS, since at least Windows 7, but not out of the box, and not for all versions. You have to actively install the NFS client, according to a quick Google search. (See https://www.reddit.com/r/Winsides/comments/1ioxr0d/how_to_create_an_nfs_share_on_windows_11/.)

    Is it possible that the lock operations are breaking because I have the build directories for these modules on a FAT32 filesystem, rather than NTFS? Wild guess.

    NFS locks obviously can only work on NFS. The tests will need an NFS export mounted somewhere to properly test.

    At least the tests 120_single.t, 130_taint.t, 200_bl_ex.t, and 300_bl_sh.t seem to lock a temp file generated by File::Temp, which will very likely NOT be on an NFS share, neither on Linux Unix nor on Windows. Also, at least 200_bl_ex.t and 300_bl_sh.t are completely skipped on Windows, because Windows does not support fork().

    Looking at the description in the POD, this sounds very fishy to me:

    Program based of concept of hard linking of files being atomic across NFS. This concept was mentioned in Mail::Box::Locker (which was originally presented in Mail::Folder::Maildir). Some routine flow is taken from there -- particularly the idea of creating a random local file, hard linking a common file to the local file, and then checking the nlink status. Some ideologies were not complete (uncache mechanism, shared locking) and some coding was even incorrect (wrong stat index). File::NFSLock was written to be light, generic, and fast.

    First, you don't need any locks for mailboxes on NFS, especially not for maildir mailboxes: Quoting the specification page https://cr.yp.to/proto/maildir.html:

    Using maildir format

    Why should I use maildir?

    Two words: no locks. [...] The maildir format is reliable even over NFS.

    (Emphasis in the original.)

    Second, creating hardlinks does not work across filesystems. You can not create a hardlink on an NFS export to a file on a local filesystem. The trick might work if you create the hardlink on the NFS export to another file on the NFS export, but NFS may cache stat() information on the client, so it might not work. I don't know.

    Maildir does not need locks, and it does not need hardlinks.

    Also, this module has not been updated since November 2018, seven years ago. At that time, Windows 11 did not exist.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]

Back to Seekers of Perl Wisdom