Version 5.38: Parallel::ForkManager = rmtree Error

[sskopnik]

Hi,
when using Parallel::ForkManager temporary directories are created for every spawned process. Later these dirs are removed using rmtree in DESTROY of Temp.pm
Using Excel::Writer::XLSX in the child processes results in an error when trying to delete these dirs. This worked fine under 5.32

Simple Test script throws:
cannot remove directory for C:/Users/mxxxxx/AppData/Local/Temp/RstWAjVdoy: Directory not empty at C:/Perl64_new/perl/lib/File/Temp.pm line 2643.
cannot remove directory for C:/Users/mxxxxx/AppData/Local/Temp/fvjigK5GMN: Directory not empty at C:/Perl64_new/perl/lib/File/Temp.pm line 2643.

# Test script
use Spreadsheet::WriteExcel;
use Excel::Writer::XLSX;
use Parallel::ForkManager;

sub genXls {
  my $pm = Parallel::ForkManager->new(2);
  
  foreach my $file ('test.xlsx', 'test2.xlsx') {
    my $pid = $pm->start and next;
    srand();
    my $workbook;
    $workbook = Excel::Writer::XLSX->new($file);
    $workbook->close() or die "Error File close";
    $pm->finish; # Terminates the child process
  }
  $pm->wait_all_children; 
}  
genXls();

[genio]

@sskopnik One issue I've noticed is that some anti-virus programs see the quick creation/deletion of temporary directories on Windows as "sketchy" and will prevent the application from functioning as expected. Can you run that again with any AV programs off during the run?

[sskopnik]

No the error persists even without AV programs activ.
Interesting fact: The generated XLSX Files should be empty but valid. They are not! Excel says they are corrupt.
There seems to be some conflicts between Excel::Writer::XLSX under a ForkManager environment (Parallel generation of Excel files) in combination with Strawberry Perl 5.38
The same script runs perfect under Strawberry 5.32 (64Bit). Here the Temp dirs are removed without any errors

[shawnlaffan]

Excel files are just zip archives so can be opened using 7zip or similar.

When doing that, the generated excel files only contain the [Content_Types].xml member. The temp dirs contain the full contents.

This looks like it could be an issue with Excel::Writer::XLSX running under Parallel::ForkManager. It could also be with File::Temp.

The runs below include $File::Temp::DEBUG = 1; in the script. The second disables the Parallel::ForkManager calls.

#  parallel
perl gh_issue146.pl
rmdir C:/Users/user/AppData/Local/Temp/dUnTH1Qilj
cannot remove directory for C:/Users/user/AppData/Local/Temp/dUnTH1Qilj: Directory not empty at C:/perls/5.38.0.1_PDL/perl/lib/File/Temp.pm line 2643.
rmdir C:/Users/user/AppData/Local/Temp/nod2DU9dgt
cannot remove directory for C:/Users/user/AppData/Local/Temp/nod2DU9dgt: Directory not empty at C:/perls/5.38.0.1_PDL/perl/lib/File/Temp.pm line 2643.

#  non-parallel
perl gh_issue146.pl
unlink C:\Users\user\AppData\Local\Temp\1x2ElZEFHN\docProps\app.xml
unlink C:\Users\user\AppData\Local\Temp\1x2ElZEFHN\docProps\core.xml
rmdir docProps
unlink C:\Users\user\AppData\Local\Temp\1x2ElZEFHN\xl\styles.xml
unlink C:\Users\user\AppData\Local\Temp\1x2ElZEFHN\xl\theme\theme1.xml
rmdir theme
unlink C:\Users\user\AppData\Local\Temp\1x2ElZEFHN\xl\workbook.xml
unlink C:\Users\user\AppData\Local\Temp\1x2ElZEFHN\xl\worksheets\sheet1.xml
rmdir worksheets
unlink C:\Users\user\AppData\Local\Temp\1x2ElZEFHN\xl\_rels\workbook.xml.rels
rmdir _rels
rmdir xl
unlink C:\Users\user\AppData\Local\Temp\1x2ElZEFHN\[Content_Types].xml
unlink C:\Users\user\AppData\Local\Temp\1x2ElZEFHN\_rels\.rels
rmdir _rels
rmdir C:/Users/user/AppData/Local/Temp/1x2ElZEFHN
unlink C:\Users\user\AppData\Local\Temp\niMBIjJrsP\docProps\app.xml
unlink C:\Users\user\AppData\Local\Temp\niMBIjJrsP\docProps\core.xml
rmdir docProps
unlink C:\Users\user\AppData\Local\Temp\niMBIjJrsP\xl\styles.xml
unlink C:\Users\user\AppData\Local\Temp\niMBIjJrsP\xl\theme\theme1.xml
rmdir theme
unlink C:\Users\user\AppData\Local\Temp\niMBIjJrsP\xl\workbook.xml
unlink C:\Users\user\AppData\Local\Temp\niMBIjJrsP\xl\worksheets\sheet1.xml
rmdir worksheets
unlink C:\Users\user\AppData\Local\Temp\niMBIjJrsP\xl\_rels\workbook.xml.rels
rmdir _rels
rmdir xl
unlink C:\Users\user\AppData\Local\Temp\niMBIjJrsP\[Content_Types].xml
unlink C:\Users\user\AppData\Local\Temp\niMBIjJrsP\_rels\.rels
rmdir _rels
rmdir C:/Users/user/AppData/Local/Temp/niMBIjJrsP

FWIW, it is also relatively common that temp dirs cannot be removed under testing. Antivirus software is a common cause but there could be other processes that scan files. OneDrive comes to mind but it hopefully does not trigger when files are created in temp dirs.

[shawnlaffan]

Possibly related: jmcnamara/excel-writer-xlsx#182

[sskopnik]

Thanks for the detailed info, which helped alot. I think it all boils down to rmtree not being threadsafe. I'm still wondering why the script works flawlessly with 5.32. Will investigate further...

[sskopnik]

I tested the parallel version of my test script unter 5.32. Here the deletion of the Temp-Dirs runs without any error. The module versions of Excel::Writer::XLSX are the same. Still have no explanation!

unlink C:\Users\m701387\AppData\Local\Temp\7j45_O8k9W\docProps\app.xml
unlink C:\Users\m701387\AppData\Local\Temp\7j45_O8k9W\docProps\core.xml
rmdir docProps
unlink C:\Users\m701387\AppData\Local\Temp\7j45_O8k9W\xl\styles.xml
unlink C:\Users\m701387\AppData\Local\Temp\7j45_O8k9W\xl\theme\theme1.xml
rmdir theme
unlink C:\Users\m701387\AppData\Local\Temp\7j45_O8k9W\xl\workbook.xml
unlink C:\Users\m701387\AppData\Local\Temp\7j45_O8k9W\xl\worksheets\sheet1.xml
rmdir worksheets
unlink C:\Users\m701387\AppData\Local\Temp\7j45_O8k9W\xl\_rels\workbook.xml.rels
rmdir _rels
rmdir xl
unlink C:\Users\m701387\AppData\Local\Temp\7j45_O8k9W\[Content_Types].xml
unlink C:\Users\m701387\AppData\Local\Temp\7j45_O8k9W\_rels\.rels
rmdir _rels
rmdir C:/Users/m701387/AppData/Local/Temp/7j45_O8k9W
unlink C:\Users\m701387\AppData\Local\Temp\zNfqF48htO\docProps\app.xml
unlink C:\Users\m701387\AppData\Local\Temp\zNfqF48htO\docProps\core.xml
rmdir docProps
unlink C:\Users\m701387\AppData\Local\Temp\zNfqF48htO\xl\styles.xml
unlink C:\Users\m701387\AppData\Local\Temp\zNfqF48htO\xl\theme\theme1.xml
rmdir theme
unlink C:\Users\m701387\AppData\Local\Temp\zNfqF48htO\xl\workbook.xml
unlink C:\Users\m701387\AppData\Local\Temp\zNfqF48htO\xl\worksheets\sheet1.xml
rmdir worksheets
unlink C:\Users\m701387\AppData\Local\Temp\zNfqF48htO\xl\_rels\workbook.xml.rels
rmdir _rels
rmdir xl
unlink C:\Users\m701387\AppData\Local\Temp\zNfqF48htO\[Content_Types].xml
unlink C:\Users\m701387\AppData\Local\Temp\zNfqF48htO\_rels\.rels
rmdir _rels
rmdir C:/Users/m701387/AppData/Local/Temp/zNfqF48htO

[sisyphus]

@sskopnik , does this (from the File::Find File::Path documentation) pertain to the failure message you're seeing:

=item cannot remove directory [dir]: [errmsg]

C<remove_tree> attempted to remove a directory, but failed. This may be because
some objects that were unable to be removed remain in the directory, or
it could be a permissions issue. The directory will be left behind.

It seems to me that there's no fatal error, and the script is actually running fine - apart form there being a couple of directories that aren't being cleaned up.
Is that what you're seeing ?

Cheers,
Rob

[sskopnik]

No, it is not a cosmetic problem. The generated (in this case empty) XLSX-files are corrupt (1kb instead of 5kb)! They can't be opened via Excel.
Try the same script with Strawberry 5.32 = All fine! The generated files are valid.

use Excel::Writer::XLSX;
use Parallel::ForkManager;

$File::Temp::DEBUG = 1;

sub genXls {
  
  my $pm = Parallel::ForkManager->new(1);
  
  foreach my $file ('test.xlsx', 'test2.xlsx') {
    my $pid = $pm->start and next;
    srand();

    my $workbook;
    $workbook = Excel::Writer::XLSX->new($file);
    $workbook->close() or die "Error File close";

    $pm->finish; # Terminates the child process
  }

  $pm->wait_all_children; # Wait for all children to complete
}  
genXls();

[sskopnik]

Hi, to get some complexity out of the equation, I removed Excel::Writer::XLSX out of my test script. Now I simply create a folder/file structure which I later try to delete in parallel via rmtree:

use Parallel::ForkManager;
use File::Path;

$File::Temp::DEBUG = 1;

sub do_rmtree {
  
  my $pm = Parallel::ForkManager->new(3);
  
  foreach my $file ('TEST/root1', 'TEST/root2', 'TEST/root3') {
    my $pid = $pm->start() and next;

    rmtree($file,1,1);    
    $pm->finish; # Terminates the child process
  }

  $pm->wait_all_children; # Warten bis alle children fertig sind!
}  

my $existingdir = './TEST';

# rmtree ($existingdir,1,1); 
mkdir $existingdir;
mkdir "$existingdir/root1";
mkdir "$existingdir/root2";
mkdir "$existingdir/root3";

open my $fileHandle, ">>", "$existingdir/root1/filetocreate.txt" or die "Can't open\n";
print $fileHandle "FooBar!\n";
close $fileHandle;

open my $fileHandle, ">>", "$existingdir/root2/filetocreate.txt" or die "Can't open\n";
print $fileHandle "FooBar!\n";
close $fileHandle;

open my $fileHandle, ">>", "$existingdir/root3/filetocreate.txt" or die "Can't open\n";
print $fileHandle "FooBar!\n";
close $fileHandle;

do_rmtree();

Under Strawberry 5.38 I get:

rmdir TEST/root1
rmdir TEST/root2
cannot remove directory for TEST/root1: Directory not empty at rmtree2.pl line 18.
cannot remove directory for TEST/root2: Directory not empty at rmtree2.pl line 18.
rmdir TEST/root3
cannot remove directory for TEST/root3: Directory not empty at rmtree2.pl line 18.

Under Strawberry 5.32.1 I get:

unlink TEST\root1\filetocreate.txt
unlink TEST\root2\filetocreate.txt
unlink TEST\root3\filetocreate.txt
rmdir TEST/root1
rmdir TEST/root3
rmdir TEST/root2

Same if I start the script nonparallel under 5.38.
It seem's that the recursion inside the _rmtree function to unlink the files inside the folders doesn't work under 5.38 using Forkmanager. But I cannot see any difference in the File::Path module.

Maybe chdir isn't threadsave in 5.38 any more?

[shawnlaffan]

I wonder if this occurs with any recent perl on Windows. @sisyphus - can you reproduce the issue using your various recent perls?

[sisyphus]

@sisyphus - can you reproduce the issue using your various recent perls?

Yes - now that @sskopnik has provided the (excellent) simplified demo, I can see it happening on my own builds of perl-5.38.0 and perl-5.39.3. (Those are the only 2 perls I've tested.)

I'm thinking it might simply be that the unlinking of the files is now not happening when rmtree() is called.
I think rmdir() then behaves as it ought in refusing to remove a non-empty directory.

I'll take a look at that later tonight ... if not beaten to it ;-)

Cheers,
Rob

[sskopnik]

Thank you! Any support appreciated!!!

I investigated a bit more. I think the problem is the following line in File::Path (sub _rmtree, line 392)

my ( $ldev, $lino, $perm ) = ( lstat $root )[ 0, 1, 2 ]
          or next ROOT_DIR;

When _rmtree is doing the recursion-call to unlink the files in dirs the lstat call fails in the parallel environment, resulting in a NEXT jump. So the files never get deleted and the rmdir later fails.

Maybe this helps for further research...

[sisyphus]

the lstat call fails in the parallel environment

Are you certain that it happens only in the "parallel environment" ?

Cheers,
Rob