 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / November 2007Possible Bug: name of directory inhibits execution?
I have written a program using MS VS VC++ 2005 Express, /cli pure. Upon compiling it it works fine in the GUI development environment. It also works fine as a Debug stand-alone. ut I had an odd behavior when it comes to the Release varsion when I renamed its project directory name it was in! I tracked the problem down to it being the NAME of the DIRECTORY the application is in! Let me explain. I compiled the code, and it worked in ALL versions, including Release stand-alone. Then I moved the entire project directory to a new location and kept the same name. It still works. Then I changed the name of the project directory by tacking on 'XXX'. It STILL works. But when I change the name by tacking on the currect date, it STOPPED working! In more detail: Directory name: ...\Project Demo\Release Works! Directory name: ...\Project DemoXXX\Release Works! Directory name: ...\Project Demo - 10-25-2007\Release DIES!! The fact it works with two different directory names proves my code access all files *relative* to current directory (i.e., the code is directory independent). Thus, directory name should be irrelevant. But, as indicated, if I tack on the DATE after the project directory name, it dies. I'm thinking it has something to do with the symbols or spaces I use in the project directory name, or its length. Haven't experimented to tell one way or another. I doubt it has to do with it being precisely the date (10-25-2007) itself, but like I said, that I have spaces and '-' symbols in it. Of course it *should* work as long as the OS allows the directory name to be valid in the first place. I can't believe the OS intentionally would allow a directory name to exist for which the name of the directory alone prevents proper execution of the applications it contains. This HAS to be a bug in the OS (operating system)!!! [==P==] >In more detail: > [quoted text clipped - 5 lines] >project directory name, or its length. Haven't experimented to tell one way >or another. I suggest you do those tests. >This HAS to be a bug in the OS (operating system)!!! I doubt it - do more tests - debug it in a folder name that gives rise to the problem. Dave > I suggest you do those tests OK, I did the tests. And this is what I found: If the Directory name is 25 characters or less long it works. It it is 26 characters or more, it doesn't. And so far it doesn't matter what the Directory is called, only how long its name is determines whether the Release version of the program (2 directory-levels lower inside it) will die or not. Note that the DEBUG version works no matter what the Project Directory is called, and Release only works if the Project Directory name is 25 characters or less in length. Actually, it is probably more tied into the LENGTH of the FULL PATH name to the application, which is used INTERNALLY by the stuff supporting my code (i.e., the OS or .NET Framework). Does that sound like INTENDED BEHAVIOR to you? Sorry, but I'm pretty sure this is a VS or OS BUG (or a hidden restriction I'm not aware of)... :) [==Peter==] PS - I can assure you this has nothing to do with my code. The only time my code accesses files is in the very beginning, where it simply loads in image files into bitmaps (Bitmap^ bm = gcnew Bitmap( "filename");) and does ZERO directory manipulation. All my files are assumed to be in the same directory as the application's 'exe' file. And nothing is full path, or else I couldn't change the directory path at all for it to work. And since it always works in Debug version under the SAME Project Directory name even if it fails under Release, well,.... PS - My program does nothing fancy, and accesses all files via relative to the application > >In more detail: >> [quoted text clipped - 16 lines] > > Dave >Does that sound like INTENDED BEHAVIOR to you? It sounds like a bug in your code (or some library code that you use). >Sorry, but I'm pretty sure >this is a VS or OS BUG (or a hidden restriction I'm not aware of)... :) I wouldn't be so sure if I were you from the evidence you've got so far! >PS - I can assure you this has nothing to do with my code. Run it under the debugger and find out where the problem is arising. >And since it >always works in Debug version under the SAME Project Directory name even if >it fails under Release, well,.... The running environment for a debug build can be subtly different from the release build. You really need to debug the release version in the situation where it's having a problem to find out the cause of the problem. Dave >> I suggest you do those tests > [quoted text clipped - 11 lines] > LENGTH of the FULL PATH name to the application, which is used INTERNALLY > by the stuff supporting my code (i.e., the OS or .NET Framework). How long is the "full path"? There is a limit at around 256 characters. > Does that sound like INTENDED BEHAVIOR to you? Sorry, but I'm pretty sure > this is a VS or OS BUG (or a hidden restriction I'm not aware of)... :) [quoted text clipped - 32 lines] >> >> Dave >>How long is the "full path"? There is a limit at around 256 characters. Yup, I think that's it! I made the directory name long enough my program didn't work. Then I moved the entire directory WITH THE SAME NAME to the root directory so it would shorten the full path name length. NOW the application works even though I changed absolutely nothing (it was not a bug in my code). Thus, it indeed seems to be that the full path name is too long and that was the problem. But this brings up another problem. WHY does the operating system let me create a directory with a path name that is too long? Shouldn't VS notice this too, and at least report it, since it created the Debug and Release directories for me? And, even worse, how many people have phoned into customer support on consumer software becuase they installed into a place that had too long a full path, even though the application is working fine? And why no WARNING, such as "you are attempting to create a directory with a full path name greater than 256 characters"? So I feel the OS needs to be changed somehow to account for this 'hidden' limitation. At least very least there should be some kind of warning as I described. I mean, do you think the public at large is aware of this? Heck, I didn't even know it, and I've been writing software using VS for many, many years. THANX BEN!!!! :) [==Peter==] >>> I suggest you do those tests >> [quoted text clipped - 50 lines] >>> >>> Dave > So I feel the OS needs to be changed somehow to account for this > 'hidden' limitation. At least very least there should be some kind of > warning as I described. I mean, do you think the public at large is > aware of this? Heck, I didn't even know it, and I've been writing > software using VS for many, many years. I agree, FWIW. The MAX_PATH limitation is completely ridiculous for a modern machine. The core OS will support paths, file names and directory names up to 32K characters, but the Win32 API is still stuck at 260 characters for most purposes. It's just DOS legacy cruft still getting in our way after all these years. -cd >I made the directory name long enough my program didn't work. So, exactly how long was it? Although 260 characters may be limiting for some, most software does accommodate it (though there have been many cases where off by 1 errors have caused problems over the years). I'd still be suspicious of a bug lurking in your code - you need to accommodate path length limits, not crash. Dave > I'd still be suspicious of a bug lurking in your code - you need to > accommodate path length limits, not crash. That's impossible. How can my code prevent an end-user from creating the directory from which he runs my code being less than a certain full path name length, when my code isn't running until it is placed in the directory from which it can't run? I bet nothing you've ever written accounts for this, does it? If so, please tell me how to write code that works without being executed? I think you have to start trying to stop blaming ME!!! LOL [==Peter==] > >I made the directory name long enough my program didn't work. > [quoted text clipped - 8 lines] > > Dave >> I'd still be suspicious of a bug lurking in your code - you need to >> accommodate path length limits, not crash. > >That's impossible. How can you say that when you've not pin pointed where in your program the crash is occurring? If you think it's an OS problem and aren't bothered if you have a real problem, then carry on ignoring the potential for a bug in your code. Try not to take my cajoling you to investigate this issue personally - we all make mistakes - I certainly do, but from experience I think the problem is most likely to be in some code you're using. If you can show us a reproducible case with some sample code that repros it and shows it's an OS problem, I'll buy you a pint. Dave >That's impossible. >How can you say that when you've not pin pointed where in your program >the crash is occurring? Please read the entire thread. The problem has been identified, and it is NOT a problem in my code. The problem is that anything which is developed that relies on the Win32 API will have problems if the files it accesses (such as with StreamReader/StreamWriter) are in a directory with too long a path name, will exit the application. Thus, if one writes code that deals in relative hard drive location addressing so the entire application can be moved and still work, then if the end-user moves it to a directory which violates the above rule it will no longer be able to access any of its resource files. How can non-running code, in fact code which ha never been run, prevent the end-user from creating such a directory and placing the application there? But I'm willing to learn! Since you obviously must be protecting against this 'full path name length' limitation in your code, please post an example of how you do this in code. Or else you have also been 'carrying on ignoring the potential for a bug in YOUR code' too, haven't you? You must have existing code for this since you are so adamant people who write code should account for this possibility, so you must already have such code. Thus, it can't be too hard for you to lift yuor code and show us how it is done. Please do! [==Peter==] >>> I'd still be suspicious of a bug lurking in your code - you need to >>> accommodate path length limits, not crash. [quoted text clipped - 13 lines] > > Dave >>How can you say that when you've not pin pointed where in your program >>the crash is occurring? > >Please read the entire thread. I believe I have - and I've not seen any code or concrete fact to indicate there's an OS bug. >The problem has been identified, and it is >NOT a problem in my code. The problem is that anything which is developed >that relies on the Win32 API will have problems if the files it accesses >(such as with StreamReader/StreamWriter) are in a directory with too long a >path name, will exit the application. So show us a small code sample that anyone can run that illustrates this supposed OS bug. FWIW, StreamReader/Writer are .Net CLR classes not Win32 APIs. Dave >>> How can you say that when you've not pin pointed where in your program >>> the crash is occurring? [quoted text clipped - 13 lines] > > FWIW, StreamReader/Writer are .Net CLR classes not Win32 APIs. Dave: As Carl explained it is not a bug in the OS, but rather a legacy defect in the Win32 API. I have to admit that all my (MFC) code will fail if the path length exceeds MAX_PATH characters, and I would be interested to know exactly what I have to do to avoid this. Of course, if Microsoft has not riddled the OS with paths like C:\Documents and Settings\<username>\Application Data\ At least this is improved in Vista (at the cost of much confusion).  SignatureDavid Wilkinson Visual C++ MVP >As Carl explained it is not a bug in the OS, but rather a legacy defect >in the Win32 API. Whatever. The _MAX_PATH character limit is what it is and applications should not crash when they encounter it. >I have to admit that all my (MFC) code will fail if the path length >exceeds MAX_PATH characters Something might fail, but it should fail gracefully, it shouldn't crash. >and I would be interested to know exactly >what I have to do to avoid this. There's no magic, just don't overwrite buffers and accommodate whatever might fail. I'm still waiting for any solid evidence of how Peter's application crashes because it's run from a folder with a long path name. In a strange way I'm hoping I'm wrong as I might be learning something new! Dave > I'm still waiting for any solid evidence of how Peter's application > crashes because it's run from a folder with a long path name. In a > strange way I'm hoping I'm wrong as I might be learning something new! The only thing I can think of that would give no chance for recovery would be a static dependency. However with StreamReader/StreamWriter the program should have a chance to recover. I can scarcely believe that there isn't an exception being thrown. Perhaps if there was a buffer overrun into a stack variable overwriting the return address... which would still be a BCL bug, not an OS bug. >I'm still waiting for any solid evidence of how Peter's application >crashes because it's run from a folder with a long path name. In a >strange way I'm hoping I'm wrong as I might be learning something new! Re-read what you wrote. How can code be written that has any control over the directory it is placed in before it is run? Note this response: > >As Carl explained it is not a bug in the OS, but rather a legacy defect > >in the Win32 API. Now please look up _MAX_PATH and then come back and tell me how to write code to avoid its limitation. If you do this I assure you, based on yuor responses, you will 'be learning something new!' My code works perfectly as far as I can tell, and I now know the situation I've described in this thread is nothing I have any control over. So all is good. After all, I might as well try to write code to prevent someone from unplugging their computer... : ) [==Peter==] > >As Carl explained it is not a bug in the OS, but rather a legacy defect >>in the Win32 API. [quoted text clipped - 19 lines] > > Dave > Something might fail, but it should fail gracefully, it shouldn't > crash. I never said my code crashed. Only you've used that word to describe it. It just exits with no errors. How much more graceful than that can you get? This is how I characterized the behavior in my OP: "But when I change the name by tacking on the currect date, it STOPPED working!" 'Stopped working' does not mean crash. It means it stopped doing what it was suppose to do. In this case, it loaded and exitted immediately with no harm to anything. It just didn't run. I'd hardly characterize that as a 'crash'. And you might note that since about my third post I've stopped labeliing what's going on an 'OS bug', but rather a legacy limitation that can cause a problem, especially if not noticed. I realized many posts ago this is NOT an OS bug. [==Peter==] > >As Carl explained it is not a bug in the OS, but rather a legacy defect >>in the Win32 API. [quoted text clipped - 19 lines] > > Dave >'Stopped working' does not mean crash. It means it stopped doing what it was >suppose to do. In this case, it loaded and exitted immediately with no harm >to anything. It just didn't run. I'd hardly characterize that as a 'crash'. OK, so why is it starting and stopping? Have you debugged it in that situation to discover why? What's the minimal code that anyone could use to reproduce this scenario? Dave The minimum code is (console project, /cli, VS VC++ 2005 Express): #include "stdafx.h" #using <System.Windows.Forms.DLL> using namespace System::Windows::Forms ; int main(array<System::String ^> ^ /*args*/) { Application::Run( gcnew Form( ) ) ; // this just falls through return 0; } But it's NOT the code, it is WHERE you place it on your hard drive before you try to execute it that causes the problem (ala the full path to the executable which attempts to launch a form). The above code also fails in the same way. I just proved it by actaully using the above code, compiling it, and put in a directory with a very long full path name. The Form doesn't launch, the application just falls through and exits. If I just change the name of the directory it is in so the full path is short enough, it then runs without changing the code at all. I believe the magic number is 120 (full path longer than 120 characters and it no longer works, shorter and it does). Can you spot any bugs in the above code? :) [==Peter==] > >'Stopped working' does not mean crash. It means it stopped doing what it > >was [quoted text clipped - 10 lines] > > Dave > The minimum code is (console project, /cli, VS VC++ 2005 Express): > [quoted text clipped - 18 lines] > the directory it is in so the full path is short enough, it then runs > without changing the code at all. Well this is a decidedly different problem from FileStream failures. Here we're dealing with paths constructed inside the .NET framework or OS, without giving you any chance to intercept the problem. I'm going to try to reproduce it... > I believe the magic number is 120 (full path longer than 120 characters > and it no longer works, shorter and it does). [quoted text clipped - 17 lines] >> >> Dave >> The minimum code is (console project, /cli, VS VC++ 2005 Express): >> [quoted text clipped - 23 lines] > without giving you any chance to intercept the problem. I'm going to try > to reproduce it... Ok, I can reproduce your problem, but I got plenty of warnings along the way. [bvoigt@voigt ...longpathname/Debug]$ ./longpathname.exe [bvoigt@voigt ...longpathname/Debug]$ mkdir -p abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcde fg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/a bcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcde fg/abcdefg/abcdefg/ mkdir: cannot create directory `abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcd efg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ abcdefg/abcdefg/abcdefg/abcdefg/abcdefg': File name too long [bvoigt@voigt ...longpathname/Debug]$ mkdir -p abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcde fg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/a bcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ mkdir: cannot create directory `abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcd efg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ abcdefg/abcdefg/abcdefg/abcdefg/abcdefg': File name too long [bvoigt@voigt ...longpathname/Debug]$ mkdir -p abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcde fg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/a bcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ [bvoigt@voigt ...longpathname/Debug]$ cp longpathname.exe abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ab cdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdef g/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ cp: cannot stat `abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abc defg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg /abcdefg/abcdefg/longpathname.exe': File name too long [bvoigt@voigt ...longpathname/Debug]$ cp longpathname.exe abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ab cdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdef g/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ cp: cannot stat `abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abc defg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg /abcdefg/longpathname.exe': File name too long [bvoigt@voigt ...longpathname/Debug]$ cp longpathname.exe abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ab cdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdef g/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ At this point I went to Windows explorer and renamed the directory containing the file. [bvoigt@voigt ...longpathname/Debug]$ cd abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abc defg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg /abcdefg/abcdefg/abcdefg/abcdefghijklmnop/ [bvoigt@voigt ...abcdefg/abcdefghijklmnop]$ ls ls: cannot access longpathname.exe: File name too long longpathname.exe [bvoigt@voigt ...abcdefg/abcdefghijklmnop]$ pwd /cygdrive/c/Programming/longpathname/longpathname/Debug/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcd efg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefghijklmnop C:\Programming\longpathname\longpathname\Debug\abcdefg\abcdefg\abcdefg\abcdefg\a bcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\a bcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefghi jklmnop>longpathname.exe 'longpathname.exe' is not recognized as an internal or external command, operable program or batch file. Ok, now I can't run the program from either tcsh, cmd.exe, or Windows Explorer. But both explorer and tcsh refused to copy it into a deeper directory, giving a coherent error message. After using subst to map into the middle of the directory tree, I can run it again. subst k: C:\Programming\longpathname\longpathname\Debug\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg [bvoigt@voigt ...abcdefg/abcdefghijklmnop]$ ls longpathname.exe [bvoigt@voigt ...abcdefg/abcdefghijklmnop]$ ./longpathname.exe [bvoigt@voigt ...abcdefg/abcdefghijklmnop]$ pwd /cygdrive/k/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefghijklmnop A symbolic link does not help. Oh, and rather nifty: [bvoigt@voigt ...longpathname/Debug]$ rm -rf abcdefg/ rm: cannot remove `abcdefg//abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/ abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcdefg/abcd efg/abcdefghijklmnop/longpathname.exe': File name too long Windows Explorer cannot delete it either, until the directory is renamed shorter. >Ok, I can reproduce your problem, but I got plenty of warnings along the >way. [quoted text clipped - 6 lines] >fg/abcdefg/abcdefg/ >mkdir: cannot create directory Ben, Are you getting those because you're building the project in that long path? If I build it and then move the exe to a long path (up to the normal 260 char limit), it crashes with a System.IO.FileLoadException. If I reduce the path length to 257 its runs OK. To summarise: This is OK: C:\1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901\clrtest.exe A single character longer gives the exception. It looks like a CLR quirk/bug to me. Dave > >Ok, I can reproduce your problem, but I got plenty of warnings along the >>way. [quoted text clipped - 11 lines] > Are you getting those because you're building the project in that long > path? No, I built it in C:\Programming\longpathname\longpathname\Debug > If I build it and then move the exe to a long path (up to the normal > 260 char limit), it crashes with a System.IO.FileLoadException. [quoted text clipped - 8 lines] > > It looks like a CLR quirk/bug to me. But if you rename the directory structure leading up to it to be longer, then the app won't even start (no exception). > Dave >But if you rename the directory structure leading up to it to be longer, >then the app won't even start (no exception). Ah, yes, I can reproduce it with a complete pathname of 260 chars. There appears to be 2 subtly different issues here: 1. A CLR program crashes when the path is > 257 characters. 2. Any program won't run (I've tried it with a plain Win32 console program) when the path is 260 characters. FWIW I'm testing on XP SP2 - dunno if Vista is any different. Dave >FWIW I'm testing on XP SP2 - dunno if Vista is any different. It's the same with Vista and XP, and both simple C# and C++/CLI programs exhibit the quirk when built for .Net 2,3, or 3.5 (beta2). I've submitted a bug report: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID =308690 Dave I knew I wasn't crazy! LOL : ) > >FWIW I'm testing on XP SP2 - dunno if Vista is any different. > [quoted text clipped - 6 lines] > > Dave >I knew I wasn't crazy! LOL : ) Validated bug (with an appropriate comment) >> >FWIW I'm testing on XP SP2 - dunno if Vista is any different. >> [quoted text clipped - 6 lines] >> >> Dave >The minimum code is (console project, /cli, VS VC++ 2005 Express): Thanks. >... >I just proved it by actaully using the above code, compiling it, and put in >a directory with a very long full path name. The Form doesn't launch, the >application just falls through and exits. That's different - I'm getting an exception when I run it from a very long path. >I believe the magic number is 120 (full path longer than 120 characters and >it no longer works, shorter and it does). Hmm, it's OK up to 257 chars for me. >Can you spot any bugs in the above code? :) No - it would appear to be a CLR quirk/bug to me. It shouldn't have any problem with path lengths up to _MAX_PATH length. Dave >> Something might fail, but it should fail gracefully, it shouldn't >> crash. > > I never said my code crashed. Only you've used that word to describe it. > It just exits with no errors. How much more graceful than that can you > get? You could print an message (or display a MessageBox) telling the user what went wrong and how to fix it (use a shorter path name). That would be better than silent failure. > You could print an message (or display a MessageBox) telling the user what > went wrong and how to fix it (use a shorter path name). That would be > better than silent failure. True. Or else, warn them clearly in the install process! Actually, why settle on one? Both together is best! :) Oddly, though, I've never seen one program that does this, even though this principle applies to almost any commercial product that does anything significant. Anybody ever seen a commercial application that does this (error message or install warning)? I know I haven't... [==Peter==] >>> Something might fail, but it should fail gracefully, it shouldn't >>> crash. [quoted text clipped - 6 lines] > went wrong and how to fix it (use a shorter path name). That would be > better than silent failure.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.