By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,677 Members | 1,174 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,677 IT Pros & Developers. It's quick & easy.

Possible Bug: name of directory inhibits execution?

P: n/a
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==]
Oct 25 '07 #1
Share this Question
Share on Google+
28 Replies


P: n/a
>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
Oct 25 '07 #2

P: n/a
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" <Da****@example.invalidwrote in message
news:1h********************************@4ax.com...
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

Oct 25 '07 #3

P: n/a
>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
Oct 25 '07 #4

P: n/a

"Peter Oliphant" <po*******@roundtripllc.comwrote in message
news:%2***************@TK2MSFTNGP05.phx.gbl...
>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).
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
"David Lowndes" <Da****@example.invalidwrote in message
news:1h********************************@4ax.com...
>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


Oct 25 '07 #5

P: n/a
>>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==]
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:eT****************@TK2MSFTNGP02.phx.gbl...
>
"Peter Oliphant" <po*******@roundtripllc.comwrote in message
news:%2***************@TK2MSFTNGP05.phx.gbl...
>>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).

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
"David Lowndes" <Da****@example.invalidwrote in message
news:1h********************************@4ax.com.. .
>>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



Oct 26 '07 #6

P: n/a
Peter Oliphant wrote:
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
Oct 26 '07 #7

P: n/a
>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
Oct 26 '07 #8

P: n/a
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" <Da****@example.invalidwrote in message
news:nt********************************@4ax.com...
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

Oct 26 '07 #9

P: n/a
>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
Oct 26 '07 #10

P: n/a
>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" <Da****@example.invalidwrote in message
news:sl********************************@4ax.com...
>>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

Oct 26 '07 #11

P: n/a
>>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
Oct 26 '07 #12

P: n/a
>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
Oct 27 '07 #13

P: n/a
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.
Oct 29 '07 #14

P: n/a
>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==]

"David Lowndes" <Da****@example.invalidwrote in message
news:hm********************************@4ax.com...
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

Oct 29 '07 #15

P: n/a
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" <Da****@example.invalidwrote in message
news:hm********************************@4ax.com...
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

Oct 29 '07 #16

P: n/a
>'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
Oct 29 '07 #17

P: n/a

"Peter Oliphant" <po*******@roundtripllc.comwrote in message
news:%2***************@TK2MSFTNGP05.phx.gbl...
>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.
Oct 29 '07 #18

P: n/a
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==]

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:ug**************@TK2MSFTNGP03.phx.gbl...
>
"Peter Oliphant" <po*******@roundtripllc.comwrote in message
news:%2***************@TK2MSFTNGP05.phx.gbl...
>>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.


Oct 29 '07 #19

P: n/a
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==]

"David Lowndes" <Da****@example.invalidwrote in message
news:j7********************************@4ax.com...
'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

Oct 29 '07 #20

P: n/a

"Peter Oliphant" <po*******@roundtripllc.comwrote in message
news:e$**************@TK2MSFTNGP06.phx.gbl...
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.
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).

Can you spot any bugs in the above code? :)

[==Peter==]

"David Lowndes" <Da****@example.invalidwrote in message
news:j7********************************@4ax.com...
>'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


Oct 29 '07 #21

P: n/a

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:uo**************@TK2MSFTNGP06.phx.gbl...
>
"Peter Oliphant" <po*******@roundtripllc.comwrote in message
news:e$**************@TK2MSFTNGP06.phx.gbl...
>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.

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...
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\abc defg\abcdefg\abcdefg\abcdefg\a
bcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abc defg\abcdefg\abcdefg\abcdefg\a
bcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abc defg\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\abc defg\abcdefg\abcdefg\abcdefg\abcdefg\abcdefg\abcde fg\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.
Oct 29 '07 #22

P: n/a
>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
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:\12345678901234567890123456789012345678901234567 89012345678901234567890123456789012345678901234567 89012345678901234567890123456789012345678901234567 89012345678901234567890123456789012345678901234567 89012345678901234567890123456789012345678901\clrte st.exe

A single character longer gives the exception.

It looks like a CLR quirk/bug to me.

Dave
Oct 30 '07 #23

P: n/a
>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
Oct 30 '07 #24

P: n/a

"David Lowndes" <Da****@example.invalidwrote in message
news:h4********************************@4ax.com...
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

Ben,

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.

If I reduce the path length to 257 its runs OK.

To summarise:
This is OK:
C:\12345678901234567890123456789012345678901234567 89012345678901234567890123456789012345678901234567 89012345678901234567890123456789012345678901234567 89012345678901234567890123456789012345678901234567 89012345678901234567890123456789012345678901\clrte st.exe

A single character longer gives the exception.

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

Oct 30 '07 #25

P: n/a
>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
Oct 30 '07 #26

P: n/a
>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/Visual...dbackID=308690

Dave
Nov 5 '07 #27

P: n/a
I knew I wasn't crazy! LOL : )

"David Lowndes" <Da****@example.invalidwrote in message
news:bo********************************@4ax.com...
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/Visual...dbackID=308690

Dave

Nov 14 '07 #28

P: n/a

"Peter Anthony" <po*******@roundtripllc.comwrote in message
news:OF**************@TK2MSFTNGP05.phx.gbl...
>I knew I wasn't crazy! LOL : )
Validated bug (with an appropriate comment)
>
"David Lowndes" <Da****@example.invalidwrote in message
news:bo********************************@4ax.com...
>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/Visual...dbackID=308690

Dave


Nov 28 '07 #29

This discussion thread is closed

Replies have been disabled for this discussion.