Don’t be helpless: What might be the reason for a "Path not found" error?

Internally at Microsoft, we have a programmer's tool which I will call Program Q. On the peer-to-peer mailing list for Program Q, somebody asked the following question:

When I try to do a q edit template template_name, instead of opening an editor window where I can modify the template, I get the following error:

Error opening for write:
The system cannot find the path specified.

Can you help resolve this error?

Okay, there is already everything you need in the error message. The program even converted the error number to error text for you. You just have to read it and think about what it's telling you.

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.

The observation that the Temp directory is completely empty suggests that the person, in an obsessive-compulsive fit, deleted everything from the Temp directory, including the 2 subdirectory. Too bad that their TEMP environment variable still contained a reference to it.

As a result, any program that wants to create a temporary file will try to create it in a directory that doesn't exist. Result: "Path not found."

The fix: Re-create the 2 subdirectory that you mistakenly deleted. (And yes, this fixed the problem.)

It somehow seemed completely surprising to this person that a "Path not found" error could possibly mean that a path couldn't be found.

Comments (74)
  1. prunoki says:

    I guess you know the people do not read rule?

  2. John says:

    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).

  3. Jason says:

    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.

  4. Brian says:

    So there's no way to vote this person off the show?

  5. Adam Rosenfield says:

    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.

  6. pete.d says:

    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.

  7. pete.d says:

    Engywuck, Adam: except that's not the scenario in question here.

    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.

  8. prunoki says:


    "Too bad that their TEMP environment variable still contained a reference to it." He did not delete something from %TEMP%, he deleted the directory that was %TEMP%.

  9. alegr1 says:

    RULE NUMBER 1 (or any small number):


    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.

  10. Guest says:


    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.

  11. shinyhat says:

    That's not helpless; that's hapless. Is this person responsible for removing the Start menu from Windows 8 as well? (please put it back, I have computer-literate grandparents)

  12. Joshua says:

    Wow. User of program Q is being an idiot and nearly half the commenters here appear to be smoking something illegal.

  13. "deleted everything from the Temp directory, including the 2 subdirectory. Too bad that their TEMP environment variable still contained a reference to it."

    That means %TEMP%=C:UsersWaldoAppDataLocalTemp2

    How did everyone miss this?  Most programs (at least mine!) assume that %TEMP% already exists.

  14. Mike M says:

    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?

  15. feh says:

    I heard one person say the definition of insanity is doing the same thing over and over expexting a different result.

  16. 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

    • The poster is helpless but not stupid, Raymond went too far

  17. dpff says:

    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?

  18. Paul M. Parks says:

    @dpff: Why are you guessing about what GetTempFileName does?…/aa364991%28v=vs.85%29.aspx

    Though, to be honest, this is the droid you're looking for:…/aa364992%28v=vs.85%29.aspx

  19. 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?"

  20. John says:

    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.

  21. Camillo says:

    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?

  22. JohnQ says:

    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.

  23. alegr1 says:

    Anyways: people have expertise a radiation oncologist isn't the right guy to go to if you have a rash.

    What if the rash appears on the radiation treatment site?

  24. This reminds me of the time I was reading a children's book and hit a WALDO_NOT_FOUND error.

  25. AECL says:


    No worries. Just throw a therac at it. Or an Israeli Sub! Gerjunimo!

  26. Anonymous Coward says:

    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.)

  27. voo says:

    @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.

    A completely unhelpful error message is something like: "Could not restore data. Error 2211.". That was the windows integrated backup tool btw.

  28. Smith says:

    @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.

  29. dave says:

    @voo:  obviously, the server is configured without a valid user path.  :-)

  30. Aaron says:

    You seem to generally dismiss the person as an incompetent fool.  (which is somewhat warranted, given the story).

    However, I'd remind you that even the most brilliant people (in any field), have bad days and occasionally make dumb mistakes.

    Maybe he just hadn't had his coffee yet after his car had a flat tire and his GF dumped him?

    In those circumstances, I understand why he might blame the tool and its error message.

  31. dpff says:

    @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?).

  32. Paul M. Parks says:

    @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?"

    Tremendous harm. Think about it.

  33. chentiangemalc says:

    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.

  34. Raphael says:

    @Mike M

    I consider every file in %TEMP% to be fair game when it comes to deleting. If a program does not want it deleted, it should keep it open without deletion rights.

  35. GetTempFileName does not know about %TEMP%.  It just creates a file in whatever folder you tell it to.

    The problem was not that the user deleted everything in %TEMP%.  That would have been fine.  The problem was that the user deleted everything in %TEMP%..

    In particular, the user rmdir'd %TEMP% itself.

    Well, actually, we don't know that the user did this; we just know that %TEMP% pointed to a folder that didn't exist.

  36. Engywuck says:

    @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 :-))

  37. Daniel says:

    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.

    This is what makes the world such a sad place.

    [Here, have a fish. -Raymond]
  38. JM says:

    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.

  39. @Samir Talwar: follow the links in the blog entry and your question will be answered.

  40. Samir Talwar says:

    @JamesJohnston: Aha. Thank you very much. I blame Google Reader for aiding me in missing those particular links. It's probably not its fault, but I'm blaming it anyway.

  41. @Samir Talwar

    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.

  42. @Raphael says:

    So just to clarify: you feel winlogon.exe (or whichever Windows process does the Term Server temp magic) should hold %TEMP% open without deletion rights?

    Because the missing folder was not in %TEMP%, but rather WAS %TEMP%.

  43. Ben says:


    Thank you. I was feeling a bit flat this morning, and your post has invoked enough rage to get me through to lunch at least!

    Waldo: Too stupid to breath, needs someone to push back and say "Use your brain idiot".

    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.

  44. Wisefaq says:

    My employer has a logon script, which amongst other things, to check for the validity of the TEMP & TMP variables.

    In the past,

    a) users* will do silly things, such as incorrectly set TEMP/TMP variables, which

    b) breaks some third party applications.

    * when I say users, I really mean that some third party program installs have done this.

  45. steveg says:

    Somewhere deep inside Microsoft someone is planning their revenge!

  46. Joshua says:

    @steveg: Preferably with kinetic rods.

  47. Paul M. Parks says:

    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.

  48. cheong00 says:

    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".

  49. Drak says:

    [Here, have a fish. -Raymond] <– Epic!

    If any of the internal tools I made goes 'boom' and someone ask me about it, I generally tell them to not use it for that scenario anymore until I get a chance to fix it.

    In this case however, it's almost like someone removing the 'Windows' directory, and then complaining windows doesn't work anymore. Don't delete system paths!

  50. Samir Talwar says:

    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.

  51. cheong00 says:

    Btw, few people even notice that %temp%<number> folder will be created by TS when login remotely. (…/243555)

  52. Daniel says:


    Reconfirming the world is full of idiots.

    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.

  53. Anonymous Coward says:

    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.

  54. voo says:

    @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.

  55. Neil says:

    @Raphael: Will that even work? I always thought deleting a folder with an open handle resulted in a zombie.

  56. Someone else says:


    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?).

  57. alegr1 says:

    Winlogon.exe needs to keep a handle to the user's %TEMP% folder, and possibly a few other such folders, to prevent this.

  58. Mike M says:

    @Raphael: And what of passing the file to a program that opens its arguments with exclusive permissions? (A terrible number of these programs exist…)

    Reading further, though, it would seem The Thing To Do would be to create a folder in %TEMP%, keep an open handle of that folder, and then place my temporary file in there.

    Of course, you'd still find the files in the subfolder to be fair game, wouldn't you?

  59. Programmerman says:

    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.

  60. Random User 437029 says:

    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.

  61. kog999 says:

    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]
  62. Adam Rosenfield says:

    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.

  63. ts bug says:

    I still think it's a design bug in terminal server. There's no need for TS to redirect the temp dir.

    [It most likely had to be done for app compat. This isn't the sort of thing you do for no reason. -Raymond]
  64. CodesInChaos says:

    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.

  65. Gabe says:

    CodesInChaos: The problem is that the "2" directory was deleted. How is creating it not solving the problem?

  66. 640k says:

    Terminal server creates the numbered temp folder each time you log in.

    Try: Log off, Log on. Fixed.

  67. Ken Hagan says:

    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.

  68. Anonymous Coward says:

    No, Raymond, your analogy doesn't hold water.

    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]
  69. Anonymous Coward says:

    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]
  70. Burak KALAYCI says:

    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 :(


    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.


    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]
  71. ts bug says:

    @Raymond: [It most likely had to be done for app compat. This isn't the sort of thing you do for no reason. -Raymond]

    Most probably NOT for any technical reason, no.

  72. Engywuck says:

    @Ken Hagan: Bonus points for calling "net use Q: \notexistinguncpath" beforehand in a non-WINS-Environment :-)

    Or, in the bad ol' times, using set TEMP=C:CONCON for nice unexpected (for the end user) results. Even saw that path once upon a time in an img-Tag in a web page… :-)

  73. Marcel says:

    [Here, have a fish. -Raymond]

    Took me a few seconds, but that one was truly, as Drak put it, epic :-)

Comments are closed.

Skip to main content