LongPathToShortPath not working!

[Japster24]

LongPathToShortPath installscript function call does not work when disable8dot3 is turned off via the following command line: fsutil behavior set disable8dot3 1

After that is ran on the command line and then you must restart your computer. Then I tried testing my installer where the LongPathToShortPath function call is used in the installscript and it no longer works.

What is the work around here? We don't want to tell our users to enable 8dot3 and restart their computers before running an installation. That is not a solution for us.

thanks!

[alegerlotz]

Japster24 wrote:
LongPathToShortPath installscript function call does not work when disable8dot3 is turned off via the following command line: fsutil behavior set disable8dot3 1

After that is ran on the command line and then you must restart your computer. Then I tried testing my installer where the LongPathToShortPath function call is used in the installscript and it no longer works.

What is the work around here? We don't want to tell our users to enable 8dot3 and restart their computers before running an installation. That is not a solution for us.

thanks!

How about using LongPathToQuote instead of LongPathToShortPath in your code?

That might be an alternative that will work in all cases. You may have to change a few things to account for file names, since you may have been applying the LongPathToShortPath to paths before appending file names, and now you'll have to do the LongPathToQuote to the entire fully qualified path name instead, but this may be your best bet.

[Japster24]

Thanks for your suggestion alegerlotz, but the value I need must go into the registry and cannot have quotes or spaces.

I might have to create an external process to use SetFileShortName API call from MS in C++ console application and walk the path. I just wanted to see if InstallShield had any default functionality that would work first.

Any other suggestions?

[joshstechnij]

The LongPathToShortPath function relies on the Windows GetShortPathName API. This API queries the local file system for the short name of the file requested. If automatic short file name creation was disabled in the registry, any files created after that point that have names longer than the 8.3 short name format will not automatically have a short name created for the file. Therefore, GetShortPathName will return no value, and in turn, LongPathToShortPath will return no value.

Generally speaking, short file names are a bit of a pain to deal with (how do you tell the difference between MyCompanyName.DllFileA.dll and MyCompanyName.DllFileB.dll when the short names are MYCOMP~1.dll and MYCOMP~2.dll) and really only exist for legacy purposes (i.e. 16-bit DOS/Win3.x applications). It is beneficial for modern applications to be able to work with paths and file names that contain spaces, particularly when Windows allows for disabling automatic short name creation.

[Japster24]

Thanks joshstechnij. I was wondering if that's the windows API that installscript function called. I wish I could change the code, but it's a function of the way the developer needs the info in the registry. The install cannot be the driving force behind a change for the developer in our case (sad, I know).

Seems you can use the 'fsutil' functionality to force a short file name even when 8dot3 is disabled. fsutil file setshortname org_filename short_filename should work. But in Window7 I get a 1314 error and I don't know how to bump user privileges to get this working. Of course even when manually doing this, I get a 305 error:

ERROR_SHORT_NAMES_NOT_ENABLED_ON_VOLUME
305 (0x131) Short names are not enabled on this volume.

Any other ideas?

Thanks!

[joshstechnij]

It would appear that disabling 8.3 name creation on Windows 7/2008 R2 for a volume prevents fsutil from setting short file names (and possibly also the SetFileShortName API), at least in a quick test I tried. Unfortunately, as this is an issue with the operating system, we do not have any information available besides what is publicly documented on MSDN. The SetFileShortName and fsutil docs on MSDN and TechNet do not indicate if manually setting short file names is not possible when 8.3 name creation is disabled. You may wish to contact Microsoft directly regarding this specific issue.

[Japster24]

Ok, I'll try some MS forums. Thanks Josh!

[Christopher_Pai]

Japster24 wrote:
The install cannot be the driving force behind a change for the developer in our case (sad, I know).

Heh, sure it can be, you just been a bigger stick. 🙂 I routinely force developers fix things on the front end with the application rather then the back end with the installer. Did it several times today.

[Christopher_Pai]

joshstechnij wrote:
Generally speaking, short file names are a bit of a pain to deal with (how do you tell the difference between MyCompanyName.DllFileA.dll and MyCompanyName.DllFileB.dll when the short names are MYCOMP~1.dll and MYCOMP~2.dll)

In fact, if those DLL's are .NET DLL's it won't work period. The assembly file names cannot change after being compiled. The CLR will throw a File Not Found exception.