Re^3: Windows NTFS UTF-16LE File-Operations

[repellent]

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.