I have the weirdest problem. Consider the following Perl script:
system('echo > echo.txt');
open(FILE, '>', "out.txt") or die "Can't open file ($^E)";
print FILE "Hello";
close(FILE);
Ignore that it is horribly written or that there are not the appropriate use strict or use warnings, for the behaviour is the same for any script. Using a recent Strawberry Perl on a recent Windows 10 Pro install on one machine, it does what you expect: it creates two files "echo.txt" and "out.txt". On another machine, with Windows 10 too and the latest version of Strawberry Perl, the script creates "echo.txt" but then the open fails with $^E set to "Access denied" (actually in Italian, "Accesso negato"). It is true for this and any other script in any directory I tried, invariably.
Of course, I checked the directory permissions: the user logged in has complete permissions inherited from the enclosing directory. I added full control for Everybody and it did not change a thing. I opened a command prompt as Administrator and launched the script there, to no avail. And, again, I tried this in a variety of directories on a couple of different physical disks.
I have uninstalled Strawberry Perl and reinstalled it but, perhaps predictably, no difference. Let me also mention that the failing PC has been installed from scratch only recently (a couple of weeks ago), but no problem whatsoever has been observed so far.
What am I doing wrong?! It must be something really silly, but I do not see it. How can I debug this?
Update #1
It turns out that everything runs fine in "c:\Users...\Downloads" but not in "c:\Users...\Desktop" nor in its subfolders nor in other directories created by the user that I could try.
Here is what dir /q says of these two folders:
c:\Users\Flavia>dir /q
Il volume nell'unità C non ha etichetta.
Numero di serie del volume: 28CE-96F1
Directory di c:\Users\Flavia
28.09.2021 14:33 <DIR> BUILTIN\Administrators .
28.09.2021 14:33 <DIR> NT AUTHORITY\SYSTEM ..
[...]
29.09.2021 09:14 <DIR> DESKTOP-TBFQ31Q\Flavia Desktop
[...]
29.09.2021 09:13 <DIR> DESKTOP-TBFQ31Q\Flavia Downloads
[...]
2 File 1’627’775 byte
24 Directory 401’441’447’936 byte disponibili
The owner is the same and is the one running the Perl script (see below). And here is what icacls says:
c:\Users\Flavia>icacls Desktop
Desktop NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
DESKTOP-TBFQ31Q\Flavia:(I)(OI)(CI)(F)
Elaborazione completata per 1 file. Elaborazione non riuscita per 0 file
c:\Users\Flavia>icacls Downloads
Downloads NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
DESKTOP-TBFQ31Q\Flavia:(OI)(CI)(F)
Elaborazione completata per 1 file. Elaborazione non riuscita per 0 file
Everyone has (F) or Full access. Clearly, the only difference is the (I) on Desktop, which I believe means that it the permissions are inherited from the parent folder. Maybe this is related to the problem (since I cannot observe any other difference) but I cannot see why and how. And, to support the fact that this (I) is irrelevant, I also checked on the PC where the script works everywhere as expected: the output difference of icacls between Desktop and Downloads is exactly the same (I) for Desktop--and, yet, there the script works equally fine in both folders.
Here is what the GUI says about the two folders on the failing PC:
I used Process Monitor to ascertain that it tries to write the correct files and, for instance, is not accidentally trying somewhere else. Here is the appropriate excerpt from Process Monitor:
Although this is a test in a subfolder of the Desktop, it is exactly identical to the failure in the Desktop. I checked the two processes which failed (perl.exe) and succeeded (cmd.exe invoked by perl.exe) and they look both healthy (in particular, the owner of the processes is as expected):
In Downloads, perl.exe succeeds but I see no difference:
I am totally clueless.
Update #2
Some discussions with people and comments here started to make me think that maybe Windows 10 has some security feature preventing the particular binary perl.exe from writing (if it is true, I have no idea of what I am talking about--and I wish I knew). Anyway, I decided to uninstall Strawberry Perl (already done, see above) and reinstall it but now using the previous version (5.32.0.1 instead of 5.32.1.1). Lo and behold, everything works like a charm. But why?! If you are tempted to think that it is a bug in the release 5.32.1.1 of Strawberry Perl, you may want to consider that on the other machine where everything works it is 5.32.1.1 which is installed. Checked the MSI installer used a couple of months ago there and a couple of days ago here: the very same file down to the last byte. Funny, uh?!
My immediate issue is solved but I still have not the slightest clue of what has happened and how I should have properly debugged the problem.