Hmm, it's just that
Win32::GetLongPathName() returns the perl string I'd most expect in Win32-land. By "expect", I mean "jives with what I see in Windows Explorer".
Using Explorer, I created a file "snowman ☃" in a new folder "my_dir". That file was created by renaming an empty text file with "snowman " first, and then copy+pasting the
snowman character. Then I ran the following:
#!perl
use Win32;
use File::Find;
use Devel::Peek;
my @paths;
find sub {
push @paths, (
$_,
Win32::GetLongPathName($_),
) if /snow/i;
}, "my_dir";
Dump $paths[0];
Dump $paths[1];
__END__
SV = PV(0x469c14) at 0x4f82b4
REFCNT = 1
FLAGS = (POK,pPOK)
PV = 0x2621844 "SNOWMA~1.TXT"\0
CUR = 12
LEN = 16
SV = PV(0x469c2c) at 0x4f82f4
REFCNT = 1
FLAGS = (POK,pPOK,UTF8)
PV = 0x262181c "snowman \342\230\203.txt"\0 [UTF8 "snowman \x{2603}.
+txt"]
CUR = 15
LEN = 16
The results tell me that the return string from
Win32::GetLongPathName() is then fit for Unicode semantics in Perl. Nevermind the underlying filesystem encoding of NTFS (UTF-16LE ? I don't know), I can now treat the path as characters from then on.
Sure, long path names are opposite of short path names. What I'm saying is that
Win32::GetLongPathName() is handy to get at the characters instead of octets given by
File::Find.