|more useful options|
Re^3: Why are there no errors when opening a filename that contains colons on Win10by rjt (Curate)
|on Oct 09, 2019 at 22:18 UTC||Need Help??|
Exactly, that goes back to what I'm saying: every operating system has its own rules for valid pathnames, and its own unique semantics for what happens when you step outside of those rules. Perl, for the most part, respects those semantics, leaving it to the programmer to decide how best to handle them. If you ask to open a file, Perl passes that request along to the OS, and the return value you get is a function of what the OS itself returns. The errors for your other cases are coming from Windows, not Perl.
I completely agree this Win32 behavior is complex and weird in spots, but it's Win32, not Perl that is giving you this behavior.
I don't follow what you mean about random characters in the output files. The print statement wrote to the files that were created successfully except for test character 8, the colon. In that case the file is empty. It seems to be a valid filehandle but the print didn't write to the file and the print seemed to succeed since it returned a true value.
See the Alternate Data Streams discussion in the MSDN article I linked. And add that to the list of surprises in support of validating your filenames! If you read back the file with the same script, you will actually get the contents back, even though foo appears to exist but be empty (and type foo outputs nothing):
This "works" because we're opening the Alternate Data Stream "bar.txt" of the file "foo". If you delete "foo", then "foo:bar.txt" will no longer be readable either.
And this nicely highlights the general issue: Perl doesn't know or care what you are opening, only whether it succeeds. Perl trusts you to know what you are asking the OS to do. Similarly, if the Windows system call confirms 12 bytes were written, Perl will take Windows' word for it. It's up to you to verify the bytes written if desired, which isn't always possible (e.g., when writing to sockets). Knowing the semantics of your target platform(s) is incumbent on you whenever you are dealing with system-level code.
Lastly, I do understand that this is experimental for you, and you have uncovered some interesting Win32 behavior. I hope these insights are helpful in answering your question.
use strict; use warnings; omitted for brevity.