"C:\PROGRA~1\COMMON~1" is a correct FULL path, as it
has an absolute base.
"COMMON1" is not a full path, as it must be resolved to its
container path.
So if GetFullPath("COMMON1") could return either
"C:\PROGRA~1\COMMON~1"
or
"C:\PROGRAM FILES\COMMON~1"
or
"C:\Program Files\COMMON~1"
or
"C:\program files\common~1"
What you want is not a full path, it's a CANONICAL path (i.e.
a path that can be compared extactly lexicographically, and
not one of its working aliases, which are working like Unix
links in a folder).
Note that even on Unix, there's no clear way to create a
unique canonical path for a given file path if the specified path
includes hard links to the final file. On Unix, only symbolic
links (to files or folders) can be resolved uniquely. Don't forget
also the case of mounted filesystems.
Conclusion: canonical paths are not necessarily unique
(including on Windows where Unix filesystems can be
mounted, for example through Samba, or through multiple
Windows shares).
What you also want is the PREFERED filename. But
sometimes, the prefered filename must be the short one, not
the LFN (think about installing shell scripts or even some
windows registry entries that need paths without spaces: not
all those will accept LFN with spaces, and not all accept
quote-delimited filenames).
Ideally all Windows applications and components should
accept quoted long filenames that embed spaces. This is not
always the case.
There may also exist limitations on the target filesystems
where files are installed/unintalled (think about Samba shares
on Linux boxes), so installers should not freely change the
letter case of filenames, even if too many applications think
that filename case is not significant.
Note that NTFS filesystems can be created on Windows with
significant case! Look at the Windows filesystem API to
determine the capabilities of a mounted volume. Then look at
the API related to mount points on NT/2000/XP (the
consequence is that it is not always sufficient to get the
filesystem capabilities at the level of the root directory of a
mounted drive or network share).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=47949
"C:\PROGRA~1\COMMON~1" is a correct FULL path, as it
has an absolute base.
"COMMON1" is not a full path, as it must be resolved to its
container path.
So if GetFullPath("COMMON1") could return either
"C:\PROGRA~1\COMMON~1"
or
"C:\PROGRAM FILES\COMMON~1"
or
"C:\Program Files\COMMON~1"
or
"C:\program files\common~1"
What you want is not a full path, it's a CANONICAL path (i.e.
a path that can be compared extactly lexicographically, and
not one of its working aliases, which are working like Unix
links in a folder).
Note that even on Unix, there's no clear way to create a
unique canonical path for a given file path if the specified path
includes hard links to the final file. On Unix, only symbolic
links (to files or folders) can be resolved uniquely. Don't forget
also the case of mounted filesystems.
Conclusion: canonical paths are not necessarily unique
(including on Windows where Unix filesystems can be
mounted, for example through Samba, or through multiple
Windows shares).
What you also want is the PREFERED filename. But
sometimes, the prefered filename must be the short one, not
the LFN (think about installing shell scripts or even some
windows registry entries that need paths without spaces: not
all those will accept LFN with spaces, and not all accept
quote-delimited filenames).
Ideally all Windows applications and components should
accept quoted long filenames that embed spaces. This is not
always the case.
There may also exist limitations on the target filesystems
where files are installed/unintalled (think about Samba shares
on Linux boxes), so installers should not freely change the
letter case of filenames, even if too many applications think
that filename case is not significant.
Note that NTFS filesystems can be created on Windows with
significant case! Look at the Windows filesystem API to
determine the capabilities of a mounted volume. Then look at
the API related to mount points on NT/2000/XP (the
consequence is that it is not always sufficient to get the
filesystem capabilities at the level of the root directory of a
mounted drive or network share).
Logged In: YES
user_id=584402
Originator: NO
As verdy_p said, this is just not what GetFullPathName does. I've updated the documentation to reflect this and note of a workaround.