Bug in WinNT 4.0 SP4 Alvaro Gilabert (agilabert@RIBA.ES) 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 (dleblanc@MINDSPRING.COM) 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 dleblanc@mindspring.com ----------------------------------------------------------------- Re: Bug in WinNT 4.0 SP4 Paul Gracy (paul.gracy@COMPGEN.COM) 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 paul.gracy@compgen.com phone: 404 705 2873 #include ========================= > -----Original Message----- > From: David LeBlanc [SMTP:dleblanc@MINDSPRING.COM] > Sent: Tuesday, April 20, 1999 10:12 AM > To: BUGTRAQ@netspace.org > 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 > dleblanc@mindspring.com ----------------------------------------------------------------- Re: Bug in WinNT 4.0 SP4 David LeBlanc (dleblanc@MINDSPRING.COM) 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 dleblanc@mindspring.com ----------------------------------------------------------------- Date: Tue, 27 Apr 1999 21:03:52 +0200 From: tschweikle@FIDUCIA.DE To: BUGTRAQ@netspace.org 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 >dleblanc@mindspring.com 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