nt4+sp4.filename.length.txt

`Bug in WinNT 4.0 SP4  
  
Alvaro Gilabert ([email protected])  
Mon, 19 Apr 1999 15:15:36 +-200   
  
Hi,  
I supose it is a bug and I will explain why do I think so  
You can exceed the limit in the number of chars allowed in a filename.   
WinNT does allow it. You can move a folder to a deeper one exceeding it.  
But, when you try to backup that folder, the backup program (BackupExec   
and WinNT Backup) crashes and reboots the server. If you try to backup   
thru a network drive (using another server and mapping that folder), then   
it crashes and reboot the server also. Not the server that is making the   
backup but the server that has the wrong folder. That's a but because WinNT,   
supposing to be a fileserver, should take care of this. Recently, Mindspring   
released a report comparing WinNT vs. RedHat, sponsored by Microsoft. This   
point was missed in the comparison.  
  
Alvaro Gilabert  
ICQ UIN 2316344  
  
-----------------------------------------------------------------  
  
Re: Bug in WinNT 4.0 SP4  
  
David LeBlanc ([email protected])  
Tue, 20 Apr 1999 07:12:23 -0700   
  
At 03:15 PM 4/19/99 +-200, Alvaro Gilabert wrote:  
>Hi,  
>I supose it is a bug and I will explain why do I think so  
>You can exceed the limit in the number of chars allowed in a filename.  
WinNT does allow it. You can move a folder to a deeper one exceeding it.  
  
That's because the limit isn't where you think it is. From the  
documentation on CreateFile in the SDK:  
  
Windows NT: You can use paths longer than MAX_PATH characters by calling  
the wide (W) version of CreateFile and prepending “\\?\” to the path. The  
“\\?\” tells the function to turn off path parsing. This lets you use paths  
that are nearly 32,000 Unicode characters long. You must use  
fully-qualified paths with this technique. This also works with UNC names.  
The “\\?\” is ignored as part of the path. For example,  
“\\?\C:\myworld\private” is seen as “C:\myworld\private”, and  
“\\?\UNC\tom_1\hotstuff\coolapps” is seen as “\\tom_1\hotstuff\coolapps”.  
===============================  
  
So it seems that if you use the APIs properly, you can deal with extremely  
long paths. When you move things around, it is very likely that you are  
dealing with relative names, not absolute names.  
  
  
David LeBlanc  
[email protected]  
  
-----------------------------------------------------------------  
  
Re: Bug in WinNT 4.0 SP4  
  
Paul Gracy ([email protected])  
Mon, 26 Apr 1999 16:36:11 -0400   
  
I must disagree. Any action that a program takes that can crash a server is  
a bug. Period.  
  
The fact that properly using the SDK and following all the 'rules of  
microsoft' would prevent the crash is not an excuse. When the application  
tries to do something that would cause a crash, the OS should whack the  
offender's knuckles (see Dr. Watson), not curl up and die.  
  
I am tired of bad code being given excuses. If MS wants to run large,  
mission-critical / business-critical systems, they should fix their code.  
  
IMHO.  
  
=========================  
Paul H. Gracy  
[email protected]  
phone: 404 705 2873  
#include <std.disclaimer>  
=========================  
  
  
> -----Original Message-----  
> From: David LeBlanc [SMTP:[email protected]]  
> Sent: Tuesday, April 20, 1999 10:12 AM  
> To: [email protected]  
> Subject: Re: Bug in WinNT 4.0 SP4  
>  
> At 03:15 PM 4/19/99 +-200, Alvaro Gilabert wrote:  
> >Hi,  
> >I supose it is a bug and I will explain why do I think so  
> >You can exceed the limit in the number of chars allowed in a filename.  
> WinNT does allow it. You can move a folder to a deeper one exceeding it.  
>  
> That's because the limit isn't where you think it is. From the  
> documentation on CreateFile in the SDK:  
>  
> Windows NT: You can use paths longer than MAX_PATH characters by calling  
> the wide (W) version of CreateFile and prepending "\\?\" to the path. The  
> "\\?\" tells the function to turn off path parsing. This lets you use  
> paths  
> that are nearly 32,000 Unicode characters long. You must use  
> fully-qualified paths with this technique. This also works with UNC names.  
> The "\\?\" is ignored as part of the path. For example,  
> "\\?\C:\myworld\private" is seen as "C:\myworld\private", and  
> "\\?\UNC\tom_1\hotstuff\coolapps" is seen as "\\tom_1\hotstuff\coolapps".  
> ===============================  
>  
> So it seems that if you use the APIs properly, you can deal with extremely  
> long paths. When you move things around, it is very likely that you are  
> dealing with relative names, not absolute names.  
>  
>  
> David LeBlanc  
> [email protected]  
  
-----------------------------------------------------------------  
  
Re: Bug in WinNT 4.0 SP4  
  
David LeBlanc ([email protected])  
Tue, 27 Apr 1999 13:13:54 -0700   
  
At 04:36 PM 4/26/99 -0400, Paul Gracy wrote:  
>I must disagree. Any action that a program takes that can crash a server is  
>a bug. Period.  
  
I did not say it wasn't a bug. A bug, by definition, is something that  
causes an application (or even the whole OS) to crash or otherwise  
malfunction. So you are not disagreeing with anything I _said_. If you  
can make something go splat, then it is a bug. No arguments there.  
  
>The fact that properly using the SDK and following all the 'rules of  
>microsoft' would prevent the crash is not an excuse.  
  
No excuses were being made. Please do not manufacture excuses when they  
are not present.  
  
The only point was that Alvaro seemed to think that it was a problem that  
moving a folder could result in a total path which is > MAX_PATH. So far  
as I know, this isn't a problem, since if you are correctly handling the  
open, you can deal with extremely long paths. I thought that others might  
have the same sort of issue, and also thought that few people would know  
that bit of arcane trivia, so I was trying to point out how you might deal  
with this correctly. In general, using API calls correctly, and knowing  
various bits of trivia from the documentation is a Good Thing, and perhaps  
might save others from having their app go down.  
  
I was NOT saying that crashing is not a bug. That would be ridiculous.  
Neither the little backup app that comes with NT, or the Seagate product  
(which as far as I know, both sprung from Arcada, which Seagate bought) are  
favorites of mine. And before anyone asks, I really don't have something I  
can recommend.  
  
  
David LeBlanc  
[email protected]  
  
-----------------------------------------------------------------  
  
Date: Tue, 27 Apr 1999 21:03:52 +0200  
From: [email protected]  
To: [email protected]  
Subject: Antwort: Re: Bug in WinNT 4.0 SP4  
  
David LeBlanc wrote:  
>At 03:15 PM 4/19/99 +-200, Alvaro Gilabert wrote:  
>>Hi,  
>>I supose it is a bug and I will explain why do I think so  
>>You can exceed the limit in the number of chars allowed in a filename.  
>WinNT does allow it. You can move a folder to a deeper one exceeding it.  
>  
>That's because the limit isn't where you think it is. From the  
>documentation on CreateFile in the SDK:  
>  
>Windows NT: You can use paths longer than MAX_PATH characters by calling  
>the wide (W) version of CreateFile and prepending *\\?\* to the path. The  
>*\\?\* tells the function to turn off path parsing. This lets you use paths  
>that are nearly 32,000 Unicode characters long. You must use  
>fully-qualified paths with this technique. This also works with UNC names.  
>The *\\?\* is ignored as part of the path. For example,  
>*\\?\C:\myworld\private* is seen as *C:\myworld\private*, and  
>*\\?\UNC\tom_1\hotstuff\coolapps* is seen as *\\tom_1\hotstuff\coolapps*.  
>===============================  
>  
>So it seems that if you use the APIs properly, you can deal with extremely  
>long paths. When you move things around, it is very likely that you are  
>dealing with relative names, not absolute names.  
>  
>  
>David LeBlanc  
>[email protected]  
  
  
  
While following this tread I tried it out. View seconds later my NT server  
rebooted.  
  
Trying to create a 'reboot-server-path' from a client - impossible. Seems as if  
such path must be created from server console. But what about a carefully  
designed program installabel on the server, using the wide variant to create  
directories - creating paths exceeding MAX_PATH then setting a share to such a  
program?  
  
WinNT crashes within this scenario, every time a client wants to access this  
share.  
One simpler scenario: install a service. Exceed MAX_PATH. Start this service at  
system startup - watch the server rebooting.  
  
THIS IS A BUG - No excuse.  
  
---  
Thomas Schweikle <[email protected]>  
  
`