Possible Bug: name of directory inhibits execution?

  • Thread starter Thread starter Peter Oliphant
  • Start date Start date
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==]
 
Peter Oliphant said:
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.
Click to expand...

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 said:
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
Click to expand...
Click to expand...
 
Ben Voigt said:
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...
Click to expand...

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.

[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
Click to expand...

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
 
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.
Click to expand...

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).
Click to expand...

Hmm, it's OK up to 257 chars for me.
Can you spot any bugs in the above code? :)
Click to expand...

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
 
David Lowndes said:
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
Click to expand...

Ben,

Are you getting those because you're building the project in that long
path?
Click to expand...

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:\1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901\clrtest.exe

A single character longer gives the exception.

It looks like a CLR quirk/bug to me.
Click to expand...

But if you rename the directory structure leading up to it to be longer,
then the app won't even start (no exception).
 
But if you rename the directory structure leading up to it to be longer,
then the app won't even start (no exception).
Click to expand...

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
 
Back
Top