Possible Bug: name of directory inhibits execution?

[Peter Oliphant]

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==]

 

[David Lowndes]

In more detail:

Directory name: ...\Project Demo\Release Works!
Directory name: ...\Project DemoXXX\Release Works!
Directory name: ...\Project Demo - 10-25-2007\Release 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 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

 

[Peter Oliphant]

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

 

[David Lowndes]

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

 

[Ben Voigt [C++ MVP]]

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

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

[==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

I suggest you do those tests.


I doubt it - do more tests - debug it in a folder name that gives rise
to the problem.

Dave

 

[Peter Oliphant]

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==]

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

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

[==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:

Directory name: ...\Project Demo\Release Works!
Directory name: ...\Project DemoXXX\Release Works!
Directory name: ...\Project Demo - 10-25-2007\Release 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 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

 

[Carl Daniel [VC++ MVP]]

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

 

[David Lowndes]

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

 

[Peter Oliphant]

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==]

 

[David Lowndes]

I'd still be suspicious of a bug lurking in your code - you need to

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

 

[Peter Oliphant]

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==]

 

[David Lowndes]

How can you say that when you've not pin pointed where in your program

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

 

[David Wilkinson]

I believe I have - and I've not seen any code or concrete fact to
indicate there's an OS bug.


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:

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

 

[David Lowndes]

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

 

[Ben Voigt [C++ MVP]]

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.

 

[Peter Oliphant]

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:

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==]

 

[Peter Oliphant]

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==]

 

[David Lowndes]

'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

 

[Ben Voigt [C++ MVP]]

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.

 

[Peter Oliphant]

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==]