#611 GetShortPathName returns incorrect result for baltic 8.3

closed-invalid
nobody
win32 (141)
5
2014-08-19
2012-09-05
Anonymous
No

GetShortPathName() returns incorrect result for 8.3 baltic file names. The returned value still contains baltic symbols although it must not.

For "õ2345678.txt" it returns "õ2345678.txt" (should be "234567~1.TXT)
For "õ23456789.txt" it returns "234567~2.TXT" (correct)

To reproduce the bug please run reproduce.bat from the archive attached. (Baltic file names should be preserved with 7zip I believe.)

Python 2.7.3, Russian Windows 7 32 bit, PyWin32 ver. 217

(Sorry, I could not find how to reopen a bug at SF.)

Discussion


  • Anonymous
    2012-09-05

    reproduction code

     
    Attachments
  • Roger Upole
    Roger Upole
    2012-09-05

    • status: open --> pending
     
  • Roger Upole
    Roger Upole
    2012-09-05

    I get the expected result for both files. If you have short file names disabled, it's possible to have files that do not have an 8.3 name.

     

  • Anonymous
    2012-09-05

    • status: pending --> open
     

  • Anonymous
    2012-09-05

    I didn't know someone could disable short file names. Anyway files on my computer are accessible via short names.

     
  • Mark Hammond
    Mark Hammond
    2012-09-05

    pywin32 is just a thin wrapper around the windows function, so I believe that the Windows implementation of GetShortPathName is what you believe is wrong.

    Note that the MS docs say:

    * If the specified path is already in its short form and conversion is not needed, the function simply copies the specified path to the buffer specified by the lpszShortPath parameter.

    * Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for [some special chars]

    So I think that the first example is already a valid short name. I'm afraid you probably need to demonstrate that calling GetShortPathName some other way (ie, not via pywin32) is returning a different value than when calling it via pywin32 before I can consider it a pywin32 issue.

     
  • Mark Hammond
    Mark Hammond
    2012-11-24

    Given I can't see how pywin32 could introduce this problem and lacking evidence that calling the function from outside pywin32 has a different result, I'm closing this as invalid.

     
  • Mark Hammond
    Mark Hammond
    2012-11-24

    • status: open --> closed-invalid