The file is
C:\Users\Waldo\AppData\Local\Temp\2\t144t4.tmp.
Therefore the path is
C:\Users\Waldo\AppData\Local\Temp\2.
I leave you to determine the next step in the investigation.

That was apparently not enough of a nudge in the right direction.

While the error message does say "The system cannot find the path
specified,"
the fact remains that I did not specify a path at all.
The path in the error message is completely unknown to me.
I could try to navigate to that path in Windows Explorer,
but I doubt that this has anything to do with resolving the problem.

Normally, I get an editor window that lets me edit the template,
but instead I get this strange error message which I've never
seen before.

I did not try to navigate to the path mentioned in the error message
simply because the mentioned Temp folder
C:\Users\Waldo\AppData\Local\Temp
is completely empty!

The helplessness is so thick you can cut it with a knife!
I also find it astonishing that the person thinks that verifying whether the
path can be found is totally unrelated to resolving a "Path not found" error.

Don't forget, this is a programmer's tool.
One should assume that the people who use it have some level
of technical skill!

Okay, first we have a "Path not found" error, and there is a
fully-qualified file name whose path couldn't be found.
First thing to check is whether the path really exists.
From the most recent reply,
one can see that the answer is "No, it does not exist."
The 2 subdirectory is missing from the
Temp directory.

Okay, so we verified that the error message is valid.
The next thing to determine is where the program got this
path from.
The person already recognized that it was the
Temp directory,
and it shouldn't be a huge deductive leap to determine that
the path probably came from the TEMP or
TMP environment variable.

Isn't it the program's job to ensure the 2 subdirectory exists? I suppose that's somewhat tangential to your point, but if I was using the program I would have reported it as a bug. Then again I would have probably ran process monitor against it to see what it was actually doing and figured it out from there (error messages may or may not be accurate; process monitor logs are the word of God).

John: For an end-user program I'd say yes. But Q is described as a programmer's tool that's internal to Microsoft. It may only do one thing, and expect everything to be set up correctly for it before it's run. It's not the hammer's job to make sure there's a nail under it.

I think it's a reasonable expectation of a program that the $TEMP directory exists (and is writable). Sure, you could make it a little more robust by trying to CreateDirectory up from the drive root if it doesn't exist, but that can fail too, and then you're back to square one. If somehow $TEMP gets set to a non-existent directory, or if $TEMP gets deleted, you want programs to complain loudly as soon as possible so that the error can be corrected.

Jason: even programmers have a right to be able to expect tools to comply with normal computer usage conventions. I'm with John on this one.

In particular, one hard-and-fast rule about the %TEMP% directory is that whatever's in there can be deleted at any time. A program that wants to keep a file alive needs to keep it locked, and of course if the program is not running at all, it has no right to expect anything to stay in the %TEMP% directory.

If you want data to stick around, don't put it in the %TEMP% directory. And that goes for directories too. Along the same lines, if you just need a place to put new temporary files, if you want a special directory under the %TEMP% directory, be prepared to have to re-create the directory if it's not there.

It's reasonable to expect that the directory referred to by %TEMP% exists. But that's "C:UsersWaldoAppDataLocalTemp". The "2" subdirectory is the program's own addition, according to Raymond's article.

%TEMP% hasn't been set to a non-existent directory. The program itself is making up a directory name that it expects to find within the %TEMP% directory and then itself complaining that it's specially-named sub-directory doesn't exist.

A SANE PROGRAM SHOULD NOT EXPECT ANYTHING EXISTING (OR NOT EXISTING) IN %TEMP%. ANYTHING THERE CAN BE DELETED AT ANY TIME.

If the author of Q doesn't understand that, what is he doing at Microsoft at all? That's the reason we get programs that will not start under an user, because its installer created values in HKCU for the Administrator. That was a problem in one release of MS Messenger.

The /2/ subfolder is added to the %TEMP% variable by terminal services, read the last link.

@Engywuck, @Adam Rosenfield

Actually "doing some mkdir to every part of the path" is not that hard, and you dont need to "trying to CreateDirectory up from the drive root if it doesn't exist", just call SHCreateDirectory or SHCreateDirectoryEx once.

That said, if the app dont want to modify user's system so rudely and decide to just return the error, its perfectly okay.

Bookmarked, so I can link to this later; I see this kind of attitude, obsessiveness and helplessness from people on mailing lists not infrequently.

@alegr1, %TEMP% is not a cache directory. If I write a program that writes to %TEMP%, closes my handle to that file, and then passes that file as an argument to another program, I have every right to anticipate that file is still there. Users and programs should not remove files they didn't create without knowing the potential impact.

If I shouldn't be using %TEMP% for transient objects, what's the point of it?

Many of the people who responded failed to realise that %TEMP% is set to the subfolder. How did that happen?

I agree with JM, the poster was not to stupid to understand the message, just too helpless to properly ask what they were really thinking – why did it even TRY to use that path? This is evident in the quote "the fact remains that I did not specify a path at all", as well as JM's quote.

So in summary:

Something odd happened to the %TEMP% variable

The program should indeed act properly, regardless of who the user is, and it does

I do have a question: if you call Win32 API GetTempFileName and if the folder specified by %T(E)MP% environment variable doesn't exist, would GetTempFileName return error of path not found? My guess is yes, since it needs to enumerate the existing files in that folder to generate the unique file name to be returned, and it cannot do so if the folder doesn't exist. Then does it make sense for GetTempFileName to create the temp folder if it is not present? What harm could it introduce by doing so?

A technical user doesn't necessarily mean technical in all areas. I know web devs that are ninjas with python etc. But through them a networking hiccup and they have no clue how to figure out if their system is connecting to the right DHCP server (there should only be one but funny how devs will run a network off their dev laptop at home then plug it in to a work network and wonder why everything goes wonky site wide).

Anyways: people have expertise a radiation oncologist isn't the right guy to go to if you have a rash. They might remember it from back in the med school days but that isn't their primary skill and what they do every day. Expecting them to remember trivia just because they learnt it once back in the day is unreasonable.

I think you still are right but for the wrong reason, it isn't that it was a technical user, it was that the error message said what is wrong fairly clearly and even if the user had no sense of what a temp directory is or that it is in the environment somewhere when led to the solution they should have been able to say "oh that makes since. I should have remembered that". Not be utterly confused. It is like a guy in church not knowing why he can't covet his neighbors ass being shown the scripture and still saying "so why can't I do that?"

I didn't realize that %TEMP% actually referenced the path with 2 in it; I assumed the program was appending the 2. About 99.9% of people are going to assume %TEMP% exists so I suspect the potential for this failure is quite high. It can still be handled programatically, of course, but I wouldn't expect it for a developer utility.

I am mildly surprised a MS developer was not able to handle the issue. Affter years of horror stories about MS hiring interviews my expectations is that only top notch engineers work there, Raymond… any clue why?

I think that this post is way too harsh. It seems like the user's ultimate difficulty was that the temporary folder was not named as he expected. (Not surprising since it was silently changed by Terminal Services.) He probably asssumed (as many posters here did), that the subfolder "2" was something the application should create. I think that, when you read a question, you should assume that the person is missing a piece of key information, and not that he is lazy and/or stupid.

I agree with JM and JohnQ. I've been in a similar situation where the software (a compiler) threw an error message in my face which was 1) completely 100% correct and 2) completely unhelpful unless you already knew what the problem was.

It is exactly the same in this case. Unless you already happened to know what TS does to your Temp folder, the error message looks like either the tool has a bug of some sort or that because of some misconfiguration or other it's trying to access the wrong path. It should be absolutely clear why the user (programmer or not) didn't think the absence of the path was the problem.

(As for JM's ‘too smart for his own good’ remark, if this is the kind of tool I think it is, more often than not simply ‘satisfying the error messages’ will set you on a coarse for cataclysmic failure. I wouldn't have created the 2 folder without knowing why it should be there; past experience has taught me that road leads straight to hell.)

@Anonymous Coward: Wait a "Path XYZ not Found" is "completely unhelpful"? I mean yes, if the obvious solution ("what happens when I just create the necessary path?") doesn't work, then you have a problem and yes it's not especially good designed, but I still expect a technically capable person to at least look whether the path exists and create it if not.

@Jason Programmers are users too; personally I think the rules of usability are too often ignored when making stuff for programmers, be it languages, IDEs, APIs… (what, you expected g++ to print a nice, short, readable message for beginners when called without arguments? Oh you! It's a compiler, silly).

But yes, Waldo should have checked that folder and made sure it existed. "I don't think it should matter, therefore it does not" is not a good rule of thumb.

@Paul M. Parks: just tried, if GetTempFileName was called with non-exist folder passed as first parameter, it will fail with error code 267 (The directory name is invalid), not 2 (did Raymond use "2" as folder name in his example?).

@dpff: The point of my response was that the documentation for GetTempFileName would lead you to GetTempPath, and the documentation for that function would tell you everything you needed to know. GetTempFileName would also lead you to a sample application that demonstrates the typical usage pattern, which is calling GetTempPath to, uh, get the temp path, and then passing that path to GetTempFileName. Of course, the documentation and the sample both point out that there is no guarantee that the temp path exists.

From your first comment:

"My guess is yes, since it needs to enumerate the existing files in that folder to generate the unique file name to be returned, and it cannot do so if the folder doesn't exist."

This is the guess I balked at.

"Then does it make sense for GetTempFileName to create the temp folder if it is not present? What harm could it introduce by doing so?"

The end user is idiot. Blows my mind people here defending this stupidity. Failures of the programmer has nothing to do with ignoring obvious error messages. Yes program should handle this scenario. Yes technical user should get & fix this error, bad program or not.

@John: so say you have some Environment Variable TEMP=C:UsersWaldoAppDataLocalTemp2 (however the 2 got at the end). Your program does some "open %TEMP%t144t4.tmp". Do you *really* want every programmer to dereference all variables and doing some mkdir to every part of the path? What if the path was intended to be on a separate drive, mounted into the NTFS namespace? (yes, that's possible).

The program does what's best: let the user decide *why* there's a "path not found". How should it know? (Assuming, of course, the program itself didn't delete the folder previously :-))

This whole issue could have been handled in a few seconds, like this: "Hey Internal Programmer User of Q, just try to navigate to C:UsersWaldoAppDataLocalTemp and create the folder '2' if it doesn't exist. Yours, …"

Instead, there are several arrogant messages going back and forth, PLUS a blog post etc.

What a waste of time just to make a helpless person feel stupid, which does not help anybody.

The person Raymond is castigating was stupid for not realizing the program was talking about the %TEMP% directory, and that programs have a habit of using the %TEMP% directory. That's all. Everyone (including Raymond) who is pretending the user was so dim they didn't understand the *semantics* of the error message is being disingenuous at best and deliberately mean at worst.

The user didn't understand that the program was accessing %TEMP%. That's all. You can see this thought process in action when they say "I could try to navigate to that path in Windows Explorer, but I doubt that this has anything to do with resolving the problem" — in other words, they didn't know *why* the program was using this particular path and not some other. This is stupid, but it doesn't seem to be the kind of stupid people are falling over.

If the user had been Pragmatic Stupid, they would have created the directory the program was asking for without understanding why, and everything would have just worked. But the user was Programmer Stupid, and programmers first want to understand why things aren't working as they expect them to. This can be a real damper on your productivity if you're too stupid to actually do that, so I guess we could call this kind of stupid too smart for its own good.

No, this is Terminal Services at work. When you log in over remote desktop, Windows will set the temp directory for the logon session to %LOCALAPPDATA%Temp<session id>, this is to avoid the possibility that the same user account could log in twice in different sessions. I'm not entirely sure, but I think Windows creates that directory when it logs on too. In order to get this kind of error, the user had to have gone to the %LOCALAPPDATA%Temp directory, deleted everything in there themselves and then tried to run the program.

Daniel: Defending the living vegetable. Reconfirming the world is full of idiots.

You know what? It's good to feel stupid from time to time; it makes you think hard before asking for help next time. Technical people should be capable of problem solving. If you can't solve this puzzle, you should consider another line of work.

So many comments seem to miss (or simply ignore) the fact that this is not only a programmer's tool, but an *internal* programmer's tool. The quality bar for such tools is usually quite a bit lower than a publicly available product like, say, g++.

I write a lot of internal tools, and I rarely spend any time making them bulletproof. They're targeted at developers on the teams I work with who have access to the tool's source code. My knee-jerk response to developers that seek "support" on these tools is, "I dunno; run it in a debugger and see what's happening." After all, that's what I would do.

It's true that every program should assume the files and folders in TEMP is deletable, but any sane person who want to clean TEMP folder do so by "disk cleaner" or by "delete when logging in as another user".

I would love to know how the %TEMP% directory got set to that location (including the "2"). Was it a third-party application, an internal tool or the user himself? If it was either of the first two, I *really* want to know why. Partially so I can keep those programs the hell away from my machine (I'd like it to work normally), but also because I want to know what possible reason anyone could have for changing the temporary directory location.

it actually is. For the intelligent, it's up to them how to deal with the idiots. If you want to rage, do so. We idiots won't care, I'm telling you. Sometimes I go to an intelligent person I do not depend on, ask a stupid question and see them rage, just for fun.

it makes you think hard before asking for help next time

I see, so the effort with the sarcastic e-mails and the blog post is an investment in the future to defeat idiocy or at least keep it at a distance.

Maybe you're right about that. I keep my fingers crossed for the intelligent that it pays off.

Voo: the error message *is* unhelpful, because unless you already know what the problem is (TS creates numbered Temp folders and one of them got deleted) the message looks like it's accessing the wrong path and provides no clue as to why or how to go about solving the problem.

The problem with people like you or Malcolm McCaffery is that every time someone else has a problem he's obviously an idiot, but if you have the problem the tool is unhelpful. I've met your clones many many times in real life. I'd ask you to pretend you didn't read the snarky blog post and imagine you were sitting at there with just that error, but I know that your kind is physically incapable of putting themselves in someone else's shoes.

@Anonymous Coward: You really don't see the difference between a non-descriptive error code and a well phrased error message? Really?

Yes after you've tested whether creating a new folder resolves the problem, you can start investigating why the program wanted that specific folder and that's probably more work (well it'd more finding out why the TEMP path was set to such a strange value – googling would've answered that one though). But for attempting to solve the problem at hand you really don't have to know *why* it is accessing that folder.

Yes I know not everybody can easily put themselves into the shoes of a person who doesn't want to use their brain before taking the easy way out and asking others for help. A horrible fault that denies the world another 100 SO questions every day about why str1 == "foo" doesn't work correctly in Java and similar things – I'm inconsolable.

The user should have looked for that path, yes. And it's true that it's better to make people learn than to just give them the "magical instructions". But you are definitely more idiot than him ("idiot" is allowed in this blog, right?).

If we're trying to teach the user, the appropriate next message in the chain here is "C:UsersWaldoAppDataLocalTemp isn't the temp folder mentioned, C:UsersWaldoAppDataLocalTemp2 is." They made an assumption that is wrong, correct their assumption.

Keep in mind, this is peer support, not user support. You're trying to help them solve their own problems, not solve their problems for them.

Sometimes I wonder if X years ago, someone invented an amazingly successful bot, designed specifically to scan blog comments and randomly select, and re-post comments into the exact same article, with optional rephrasing. Then I remember that most people (apparently) comment on articles before (optionally) reading the comments.

I think at least part of the point that Raymond was trying to make and that seems to be lost on some is that the user most likely did not even attempt to troubleshoot in even the smallest degree and that’s what upset him more than the user not being a computer expert. It was just a gut reaction of error message email developer. As an internal tool this isn't John Q. Public, it’s someone who works for MS, now they may not be a developer but I would hope that had at least a basic understanding of computers and windows to be able to get going down the right tract of troubleshooting. The error message tells them right there what the problem is path not found and what path it is looking at. In the reply the user even states that they reluctantly (as if it was a huge burden for them to do) browsed all the way to TEMP but it was empty as in no 2 folder. Again after exerting the minimal effort possible the shut their brains off and pushed the problem on to someone else. If they had put any effort into it there next question might have been hmm /2 that’s an odd path I wonder why it’s using that and they could have easily goog… emm, binged for the answer. They could have at least tried creating a /2 folder to see what happened but they just wanted someone to do it all for them.

[Not even "Gosh what's this 2?" It's like "The error message says the path can't be found. The path is BlahblahTemp2. But BlahblahTemp is just fine!" Yeah, but BlahblahTemp isn't what the error message was complaining about. It's like saying, "You told me the book is not available in the library. But the library is right there!" -Raymond]

If Terminal Services gave its $TEMP subfolder a more meaningful name such as "TSTemp<number>" instead of just "<number>", people would be less confused and more likely to be able to figure this out on their own. "TSTemp2" is a much more eyebrow-raising name that's easier to search for online, whereas "2" is opaque enough that most people would just ignore it rather than try to search for it.

I admit that I'm not sure if I would have solved the issue. %TEMP% pointing to C:UsersWaldoAppDataLocalTemp2 instead of C:UsersWaldoAppDataLocalTemp is certainly surprising for me. Probably I would have printed %TEMP% after some time, and learned that it isn't the program that's weird, but that it's windows that's weird. And even that doesn't tell you why %TEMP% points there. Sure it makes sense once you know what's causing it(prevent concurrent sessions from interfering or something like that), but figuring it out if you don't know isn't that obvious IMO.

Obviously I could have created the 2 directory to make the error go away. But that's not solving the actual problem, that's just curing the symptoms without understanding the cause.

You *could* just insist that the OS creates TEMP when necessary. That would work. Right up to the day when I maliciously:

set TEMP=Q:DriveNotFound

So… since you can't fix the problem *reliably*, programs have to cope with this error anyway and if they have to cope with the error, why not just let it happen when someone naively blows away their own TEMP directory.

Bear in mind also that in this case Terminal Services *did* create the TEMP directory. The user must have blown it away after logging in.

The point is that the error message prima facie doesn't help in diagnosing the cause of the problem. It's like when you ask someone to repair your bicycle and he comes back the next day saying that he cannot find the book ‘On Gnomes and Kobolts’ in the library.

[I'm assuming that if a developer gets the error message "path not found trying to access file X", they should know to check whether the path to file X can be found. Saying "I checked the path to Y, and it's good" is missing the point of the error message. -Raymond]

Raymond, don't be obtuse. It's obvious to everyone here that the path mentioned couldn't be found. But that is not the issue. As the user said, it looks like the tool was accessing the wrong path or maybe hit on a configuration problem or something, and the (in)accessibility of the path seems irrelevant. Unless you already knew what the problem was, the error message was no help.

If the bicycle repair man complained he couldn't find ‘On Gnomes and Kobolts’ your first reaction would be to look for a different repair man, or if he's the only one in town, talk to his friends and family and maybe the local shrink.

[If the error message is "path not found" and you think the path is the wrong path, then the question you should ask is "Where did this bogus path come from, and how do I get the program to use a valid one?" Not "I got an error. Wha?" At least try some basic troubleshooting first. -Raymond]

I think for this one Raymond has all bases covered because it is an (1)internal (2)programmer's tool (3)at Microsoft.

So one cannot really nitpick about how the wording of the error message is misleading :(

Still,

Raymond> I also find it astonishing that the person thinks that verifying whether the path can be found is totally unrelated to resolving a "Path not found" error.

Raymond> …first we have a "Path not found" error, and there is a fully-qualified file name whose path couldn't be found. First thing to check is whether the path really exists.

Why?

The program says the system cannot find the path… Why would you (as the user) verify anything further? Of course the path does not exist, you don't need to verify it. If it did, the system would have found it! Don't you have any faith in the system?

Alternatively, if the program was in error, displaying an unrelated/incorrect error message, then again verifying that will only help finding out this. Then what? Will it help resolving the issue, or just make you label the issue as un-resolvable.

Verifying the path would not have helped (Waldo) resolving the issue. It would have helped the author of the program, it could have helped resolving a bug in Windows where it cannot find a path which did exist. It would be a waste of time for Waldo, he should have assumed the path did not exist right away…

[Verifying the error message is an important first step. Otherwise you may end up running in the wrong direction. -Raymond]