| Date: | December 24, 2004 / year-entry #433 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041224-00/?p=36893 |
| Comments: | 22 |
| Summary: | When you set environment variables with the System control panel, the TEMP and TMP variables are silently converted to their short file name equivalents (if possible). Why is that? For compatibility, of course. It is very common for batch files to assume that the paths referred to by the %TEMP% and %TMP% environment variables do... |
When you set environment variables with the System control panel, the For compatibility, of course. It is very common for batch files to assume that the paths referred to by the I say "if possible" because you can disable short name generation, in which case there is no short name equivalent, and the path remains in its original long form. If you are crazy enough to set this value and point your |
Comments (22)
Comments are closed. |
Speaking of which… Ever since I first tried Windows 95 I’ve been wondering why Microsoft chose to name a very important folder with a long, embedded-space name. I’m talking about "Program Files", of course.
My only hypothesis so far is that they wanted to demonstrate that VFAT worked well enough to store every application file under a folder that used the newfangled naming capacities. Hubris ? Although they did not go as far as calling the default systemroot directory "Windows Files" or somesuch, so they had to know that it was still a slightly risky business.
What was wrong with "Programs" ?
Cheers,
–Jonathan
Interestingly, even if you don’t touch the short file name generation option, some programs still die horribly (with odd errors) if your TEMP directory has a space in it.
This causes problems, of course, in environments where TEMP is set (by default) to %USERPROFILE%Local SettingsTemp…
I leave short name generation on not for compatibility reasons but just because it saves typing "m files" and "ments"; instead, I can just type progra~1 and mydocu~1. Sure, I could change these obnoxious directory names to something else on my system, but I regularly end up using computers I have no control over, so I try to get myself into transferable time-saving habits and avoid ones that require special touches.
It always amuses me when applications create paths like C:Program FilesSuper Company Corp (Registered Trademark)Brilliant Application For WindowsVersion 1.0ProgramBrillApp.exe. They usually come with an equally-bad set of Start Menu items, usually containing something like Super Company Corp (Registered Trademark)Brilliant Application For WindowsBrilliant Application For Windows Version 1.0.lnk.
I remember back on my Win95 system, which was the first time I’d used Win95, I had about ten different C:Progra~1Micros~n directories. Fortunately, with the benefit of experience I now always override install directories and call them something shorter and more sensible. I also get angry when installers create new entries without asking me what they should be called.
Things were much easier when TEMP usually lived in C:WINDOWSTEMP. :)
I suppose "Program Files" got a space in it to force application developers to tackle the problem. If the default name didn’t contain a space, many more programs would still have problems with it.
A sidenote: It is fun to use a command-line (cross-)compiler with makefiles. And then install the compiler and your build tree in locations with spaces in the file names :-)
"It turns out that ADI wanted to RunOnce a program in "C:Program FilesAnalog Devices", but since they didn’t quote the filename, and since my web stats program Analog lives in the aforementioned folder, the folder’s what I got."
Have you ever see what CreateProcess does to figure out unquoted file names? Maybe Windows uses the "break at the spaces" algorithm to disambiguate folder references the way it does files.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
Re: M Knight: (why disable short name generation)
one word: benchmarks
The extra I/O(s) to check if the generated short names are unique cause Windows as a file server to lose ground to other file servers which don’t generate short names.
I think that complaining about being able to move forward is a first for this blog. :-)
Note that SFN generation has several interesting side-effects. First, on FATxx, the short names are stored in the OEM character set which causes some interesting aliasing. Second, since the first three characters of the extension are preserved, "dir *.doc" does return the "my.doctor" file much to people’s confusion.
Short file names can also save you from Windows inconsistency. I once found a file on my desktop which had a dot as the last characters. It was impossible to delete with the shell or from a command prompt because Win32 usually removes trailing dots from file names. The only way to remove the file was by using its short file name.
I want to hurt who ever thought disabling short name generation was a good idea and then pushed it as an ‘optimization’.
The only time it makes a differences is when the file is created, and the disk IO for making the original file name vastly overshadows and potential benifit derived from a 20-40bytes of savings on disk.
And if you need to have hundreds/thousands of files created per second, I need to ask what the *hell* are you doing? An Installer I can understand, but for ‘normal’ IO file use?
Disabling short file name generation can make a big difference for applications that for whatever reasons want to create a lot of files (> 100,000) in the same directory.
> The only way to remove the file was by using its short file name.
"del \?c:foo." would also work.
"I suppose "Program Files" got a space in it to force application developers to tackle the problem. If the default name didn’t contain a space, many more programs would still have problems with it."
I’m surprised Frank and other commenter’s don’t see the point of this decision given they read Raymond’s blog (and I imagine that "forcing" developers to do *anything* was not that point.)
The simple fact is that before "Program Files" there was no standard place to install applications (remember c:winword or changing the install directory to c:apps… or d:apps… as a habit.) Enforcing a new standard on new applications mattered very little.
OTOH C:WINDOWS was a location that many, if not most, applications expected to exist. It would have caused quite some upset to applications and to users if it hadn’t. That assumption has continued till very recently – it’s almost certainly the reason Windows XP uses that directory name over the Windows 2000 C:WINNT.
I am glad "program files" has a space in it. Whenever I installed an application that warned against installing it under a path with a space in it, I just aborted the install. The space in "program files" helps me avoid cr*pware.
If "program files is too long to type, just use tab completion.
I used to have a standard directory, under Windows 3.x, called "C:Programs", which held my useful stuff like the Borland grep program and assorted batch files to put the DOS window into 50 line mode (tho I discovered recently that my fingers STILL remember how to type MODE CON:LINES=50 without hesitation – ah, muscle memory…). I think the reasons for the "Program<space>Files" directory, in descending order of usefulness, must have been:
1. You’re guaranteed that nobody who’s upgrading from Win 3.1 to Win 95 will already have a directory of that name on their system, so there’ll be no clashes with pre-installed Win 3 software.
2. In the spirit of making Windows easier to use (aka Macintoshifying?), "Program Files" is fairly self-explanatory, although it might have been beaten by "Application Files" if Apple hadn’t got there first…
3. Such an omnipresent reminder of the new Long File Name feature could only be a good thing, for users and developers both — not just to encouraging debugging of programs, but also to remind people that they no longer needed to cram their filenames into a too-small space (no more PHDTHSS1.DOC for the first draft of their doctoral work…)
(Incidentally… I think the LFN system was the best thing about Win95. I remember my Mac friends gloating that they’d had it for years, so obviously WIN95 = MAC84. When the Mac finally got a command-line built in, I tried asking them if that meant OSX = MSDOS1, but they didn’t answer…)
Jonathan Perret: The most obvious reason would be to make the OS more friendly to users. Of course, in an ideal world, users shouldn’t need to worry where programs are installed.
Ben Cooke: In the command line, you can use tab completion. In path boxes (such as in the Run dialog) you can use the autocomplete feature. Maybe Microsoft should turn off short file names for a couple of Longhorn betas and try to make software makers fix their programs.
A few years ago I knocked my head against a solid wall trying to figure out why on Earth SQL Server SP2 would refuse to install. Turned out that
SET TEMP=C:Temp
SET TMP=C:Temp
would do. Previously the two variables were "C:Documents and SettingsAdministratorLocal SettingsTemp" (without the quotes :))
And speaking of idiotic programs… The latest version of Yahoo! Messenger refused to install the first time I tried it on a Windows machine on which my account was roaming and which had a home share. It turns out that YM tries to invoke regedit and gets the path to the Windows folder by using the HOMEDRIVE environment variable. In my case, it was H:
YACR (Yet Another Case of RTFM).
I never quite understood why the shell refuses to perform routine file operations on filenames that can be used and created programmatically just fine, which leads to a severe problem when that happens. (.htaccess, stuff., certain invalid characters, and so on.)
Maybe Raymond can shed some light on it in the future, or has and I missed it.
That is not the only bug, nor is this minor.
I lost my windows directory once because
command.com didn’t ignore trailing spaces in:
set W=C:windows<SPACE>
rm -rf %W%temp
expands to:
rm -rf c:windows temp
One more XP/win2k bug, windows media player has
hardcoded TEMP to the default. I changed it in
IE and media player started dying. I had to get
rid of media player (I like my TMP=c:/tmp).
That is how the media player lost the day
— too much hardcoding, does no one at MS use
$TMP different from the defaults? Amazing.
– Mosh.
>If you are crazy enough to set this value and point your TEMP/TMP variables
>at a directory whose name contains spaces and doesn’t have a short name, then
>you get to see what sorts of things stop working properly.
I always turn off 8.3 filename creation because it just adds unnecessary overhead and I’ve never found anything that needs them… with one exception, *(#$&^&* InstallShield. It’ll create directories with long filenames, but then dies silently when it can access them 8.3 format. The only way I’ve found to get this to work is to freeze the installer process after it’s created the directory and written the about-to-install files to it, rename the directory to its 8.3 form, and then unfreeze the installer. Thankfully the adoption of the MSI system seems to have ended this braindamage.
Foxy,
Probably for the same reason there STILL is no sort-by-extension in Explorer: somebody up there knows better than us how we want to organize our data.