in reply to Windows LFN to 8.3 trivia

I see that you are using Win32::GetShortPathName. There is a corresponding Win32::GetLongPathName, where you pass it a short name path and returns into a buffer a long name path. It states that it's present for all platforms, 95/98/NT/W2K.

Unless I misunderstand the goal (which could be entirely the case), could you not loop through the unpacked files in a directory, convert the name using GetLongPathName, then rename them to the resulting LFN?

I haven't tried this, but was basing this on my browsing of the MSDN.

--Chris

e-mail jcwren

Replies are listed 'Best First'.
(tye)Re: Windows LFN to 8.3 trivia
by tye (Sage) on Mar 28, 2001 at 21:18 UTC

    That would be a "chicken and egg" problem. You could do what you suggest if you already had the files named with long names. That is, the files are extracted with names like "2001_0~4.TIF" so GetLongPathName() will return "2001_0~4.TIF" (that is the only name that the file system has been given for that file).

    I worry that even the original solution is not enough as the encoding depends on the order in which the files were created (that is, it is not uniquely determined from the set of file names)! Unless the files are listed in "creation order", you can't recover the long names from just the short names!

            - tye (but my friends call me "Tye")
[reply]

      You are correct about the way that GetLongPathName() will work.

      My first attempt was to sort files by the time stamp, and rename them in that order from the index. But, apparently the files were created in various places and then moved into the same directory at some point. The index order is the creation order. This happy coincidence is the reason I've called this 'a workaround in the bad sense'.

      By the way, I think that the "budget constraints" excuse for not fixing this means, "I don't have time or staff to look into your problem", not "we can't afford different software".
      mkmcconn

[reply]

In Section Seekers of Perl Wisdom