When the 0.22.2 release saves the incoming messages
the naming format used is "popfileXX.msg" where XX is a
two-digit hex number. There are 9 characters in the
"popfileXX" part of the name which makes this a LFN so
Windows has to generate a SFN alias for every message
file.
On NTFS-based systems LFNs which start with the
same characters (like these message files where the first
7 chars are identical) cause a significant increase in the
time taken to create the files. The increase occurs
because NTFS bases the SFN alias on the first six
characters of the LFN. Repeated conflicts between a
generated SFN name and existing SFN names cause
NTFS to regenerate the SFN name several times (up to 8
times?).
Disabling SFN support is not an option because SFNs
are used in POPFILE_ROOT and POPFILE_USER
(POPFile does not work properly if these environment
variables contain spaces).
A simple one-byte patch to History.pm will make
POPFile generate 8.3 format names to avoid the
Windows overhead involved in generating an SFN alias
(line numbers refer to the file shipped with 0.22.2):
Change line 777 (in 'get_slot-file') from:
my $file = 'popfile' .
to:
my $file = 'popfil' .
This patch has the side-effect of leaving empty sub-
folders in the 'messages' folder when history files are
deleted, so another one-byte patch is required:
Change line 345 (in 'release_slot') from:
$file =~ s/popfile[a-f0-9]{2}\.msg$//i;
to:
$file =~ s/popfil[a-f0-9]{2}\.msg$//i;
Changing "popfile" to "popfil" (in both patches) seemed to
be the simplest way to stop using LFNs.
If you want to try these patches: clear the message
history, shutdown POPFile, make a backup copy of
History.pm, make the changes to History.pm, if there are
any message files in the 'messages' structure change
their names to the new format (so the patched version of
POPFile will be able to access and/or delete them) and
start POPFile.
For further details see this thread:
http://sourceforge.net/forum/forum.php?
thread_id=1312553&forum_id=230652