🚀 go-pugleaf

ianst@qdpii.ind.dpi.qld.gov.au (Ian Staples) writes:

>I found this by accident, the following sequence of commands was
>deliberately used to confirm the bug (note: assumes PROMPT is $p$g):

>cd \				;get yourself into the drive root
>md xyz				;make a directory, any name will do
>cd xyz				;get into it
>md xyz				;make a subdirectory with the same name
>				;but *don't* change into it
>label a: abcdefgh		;any legal name will do - you *do* have
>				;a disk in drive a: don't you?  ;-)

>Now have a close look at your prompt - if you have the bug too, it
>will read C:\XYZ\XYZ> instead of the expected C:\XYZ> 

Cute!  I just confirmed it; I'm running MS-DOS 6.2 (US flavor).

Joe Morris / MITRE

In article <CLtt1E.Lvv@qdpii.ind.dpi.qld.gov.au>,
Ian Staples <ianst@qdpii.ind.dpi.qld.gov.au> wrote:
>I would be interested to hear if others can duplicate this problem.
>Also, it would be most interesting to learn what is causing it, if
>any MSDOS gurus out there (Microsoft or independent) care to offer
>a diagnosis.
>
>I found this by accident, the following sequence of commands was
>deliberately used to confirm the bug (note: assumes PROMPT is $p$g):
>
>cd \				;get yourself into the drive root
>md xyz				;make a directory, any name will do
>cd xyz				;get into it
>md xyz				;make a subdirectory with the same name
>				;but *don't* change into it
>label a: abcdefgh		;any legal name will do - you *do* have
>				;a disk in drive a: don't you?  ;-)
>
>Now have a close look at your prompt - if you have the bug too, it
>will read C:\XYZ\XYZ> instead of the expected C:\XYZ>  [assuming you

Well, it's not really as bad as you'd think- I tried it on 6.2 and got the
following results:

Assume you have a set of directories all in series, all the same name,
such as \x\x\x\x\x\x\x\x (like your \xyz\xyz).
Now if your'e in \x and use label, you get \x\x.
If in \x\x and use label, you get \x\x\x\x.
If in \x\x\x and use label, you get \x\x\x\x\x\x
But now for the good news, anything \x\x\x\x or above has no effect.  So
from now on just name all your directories 4 levels deep :).

(kinda strange as the directory level label puts you in is twice as deep
as you were before calling label ).

Mike
kahlerm@seattleu.edu

-- 
this .signature intentionally left blank

jcmorris@mwunix.mitre.org (Joe Morris) writes:

> ianst@qdpii.ind.dpi.qld.gov.au (Ian Staples) writes:
> 
>>I found this by accident, the following sequence of commands was
>>deliberately used to confirm the bug (note: assumes PROMPT is $p$g):
> 
>>cd \                           ;get yourself into the drive root
>>md xyz                         ;make a directory, any name will do
>>cd xyz                         ;get into it
>>md xyz                         ;make a subdirectory with the same name
>>                               ;but *don't* change into it
>>label a: abcdefgh              ;any legal name will do - you *do* have
>>                               ;a disk in drive a: don't you?  ;-)
> 
>>Now have a close look at your prompt - if you have the bug too, it
>>will read C:\XYZ\XYZ> instead of the expected C:\XYZ> 
> 
> Cute!  I just confirmed it; I'm running MS-DOS 6.2 (US flavor).

Happens on MS-DOS 5.0/4dos too.
-- 
       Roy M. Silvernail         [ ]  roy@sendai.cybrspc.mn.org
head -2 /usr/philosophy/survival  |      PGP 2.3a public key
#! /usr/local/bin/perl -n         |      available upon request
next unless /$clue/;              |      (send yours)

In <CLtt1E.Lvv@qdpii.ind.dpi.qld.gov.au> ianst@qdpii.ind.dpi.qld.gov.au (Ian Staples) writes:
>I would be interested to hear if others can duplicate this problem.

>Now have a close look at your prompt - if you have the bug too, it
>will read C:\XYZ\XYZ> instead of the expected C:\XYZ>  [assuming you
>are working on drive C: like me - I don't know if the same thing
>happens for other drives, or for network drives (guess I should try 8-) ]

Happens in MS-DOS 6.2 too.  The sample problem is not as serious 
as you think because your example made us create a second subdirectory
but did not take us there at that point.  Hence it is empty.
The DEL *.* would have no effect after the bug took us there. 

Happens in other source and target drives too.

OK, having done more tests, I concede that the problem is there
where you _already_ had any two directories with the same name
and containing files.

For example, I have C:\TEMP, where I tend to throw newly downloaded
files.  As they are archived, I unpack them one at a time in
C:\TEMP\TEMP.  So both directories tend to have files in them.

It is not a new bug, so no cigar.  The LABEL command has a few
other bugs as documented in the Knowledgebase CD-ROM.

-- 
=========================== Ash Nallawalla VK3CIT ===========================
Dial USA (914)876-6678 (recordings) to find your nearest computer user group.

jcmorris@mwunix.mitre.org (Joe Morris) writes:

>ianst@qdpii.ind.dpi.qld.gov.au (Ian Staples) writes:

>>I found this by accident, the following sequence of commands was
>>deliberately used to confirm the bug (note: assumes PROMPT is $p$g):

>>cd \				;get yourself into the drive root
>>md xyz				;make a directory, any name will do
>>cd xyz				;get into it
>>md xyz				;make a subdirectory with the same name
>>				;but *don't* change into it
>>label a: abcdefgh		;any legal name will do - you *do* have
>>				;a disk in drive a: don't you?  ;-)

>>Now have a close look at your prompt - if you have the bug too, it
>>will read C:\XYZ\XYZ> instead of the expected C:\XYZ> 

>Cute!  I just confirmed it; I'm running MS-DOS 6.2 (US flavor).

I got it happening too. But I am using MS-DOS 5.0!  So I guess this
bug has been with us for at least 3 major releases. Can any 3.2 and
4.0/1 users try to recreate the bug?

-- 
_____________________________________________________________________________
Tooraj Enayati     Melbourne    Australia   tooraj@daneel.rdt.monash.edu.au

: I got it happening too. But I am using MS-DOS 5.0!  So I guess this
: bug has been with us for at least 3 major releases. Can any 3.2 and
: 4.0/1 users try to recreate the bug?

: -- 
: _____________________________________________________________________________
: Tooraj Enayati     Melbourne    Australia   tooraj@daneel.rdt.monash.edu.au

Just tried it on an original IBM PC running PC DOS 3.3 and it does NOT 
happen.  You stay in the same directory.  The problem probably occurs 
because DOS uses FCB's to write the label on the A: drive.  Therefore it 
must change the default to A:\, write the label and then change the 
default back to the original drive:directory.  There is probably a 
bug in the way the original directory information is stored.  It does 
bear some investigation.  Anyone willing to spend a few hours with DEBUG?

OK...Forget the few hours with DEBUG.  A simple INT 21 intercept program 
points up the bug.  LABEL gets the current directory with INT 21 function 
47, which does not give drive and root, only path.  This string is fed 
through the undocumented function 60 to get the fully resolved 
drive:path.  (This will account for a SUBST or ASSIGNED or JOINED 
drive.)  If there is a subdirectoy which has the same name as the 
current directory, that name is reported back as the fully resolved path 
and not the current directory.  Try it yourself. Switch to the 
subdirectory, and type TRUENAME "TEMP".  If there is a TEMP in the 
subdirectory the return is C:\TEMP\TEMP.

Naturally when the LABEL program switches back to the directory from 
which it was called, it switches to the wrong directory.  This isn't a 
bug, it's a feature!  I guess no one at MS has ever made a subdirectory 
with the same name as the parent and used the LABEL program.  

panda@marlin.ssnet.com (Pamela Kane) writes:

>drive.)  If there is a subdirectoy which has the same name as the 
>current directory, that name is reported back as the fully resolved path 
>and not the current directory.  Try it yourself. Switch to the 
>subdirectory, and type TRUENAME "TEMP".  If there is a TEMP in the 
>subdirectory the return is C:\TEMP\TEMP.

Uhh.. if you're in a directory called C:\TEMP, and there's a
sub-directory in it called TEMP, and you type TRUENAME TEMP, the
expected result _IS_ C:\TEMP\TEMP.  You are asking for the truename of
the subdirectory of the directory that you are in.

Cheers

--
Andrew Derry - derry@sfu.ca

>>>>> "TE" == Tooraj Enayati <tooraj@daneel.rdt.monash.edu.au> writes:

TE> jcmorris@mwunix.mitre.org (Joe Morris) writes:

>ianst@qdpii.ind.dpi.qld.gov.au (Ian Staples) writes:

>>I found this by accident, the following sequence of commands was
>>deliberately used to confirm the bug (note: assumes PROMPT is $p$g):

>>cd \				;get yourself into the drive root
>>md xyz				;make a directory, any name will do
>>cd xyz				;get into it
>>md xyz				;make a subdirectory with the same name
>>				;but *don't* change into it
>>label a: abcdefgh		;any legal name will do - you *do* have
>>				;a disk in drive a: don't you?  ;-)

>>Now have a close look at your prompt - if you have the bug too, it
>>will read C:\XYZ\XYZ> instead of the expected C:\XYZ> 

>Cute!  I just confirmed it; I'm running MS-DOS 6.2 (US flavor).

TE> I got it happening too. But I am using MS-DOS 5.0!  So I guess this
TE> bug has been with us for at least 3 major releases. Can any 3.2 and
TE> 4.0/1 users try to recreate the bug?

No problems under MS-DOS 4.01 -- my guess is that the bug was introduced in
5.0, since that's when the user interface was changed to allow entering the
label name on the command line.  I wonder, just how many other FCB-based
DOS utilities might exhibit the same problem?

Regards,

Gary
--
/ Gary A. Hildebrand                 Internet: gah@mew.mei.co.jp       \
/  Matsushita Electric Works, Ltd.   UUCP:     uunet!mew.mei.co.jp!gah \
/   13-2, Mita 5-chome, Minato-ku    Fax:      03-3451-0793            \
/    Tokyo 108, JAPAN                Tel:      03-3452-4941            \

gah@trc.mew.mei.co.jp (Gary A. Hildebrand) writes:

>No problems under MS-DOS 4.01 -- my guess is that the bug was introduced in
>5.0, since that's when the user interface was changed to allow entering the
>label name on the command line.

Yes, I had a friend check it with MSDOS 3.3 last night and there was no
problem with it either.
-- 

Ian Staples                        E-mail : ianst@dpi.qld.gov.au
c/- P.O. Box 1054 MAREEBA          Phone  : +61 (0)70 921 555 Home 924 847
Queensland Australia 4880            Fax  : +61 (0)70 923 593   "   "   "

In article <2kq5g0$rq@marlin.ssnet.com> panda@marlin.ssnet.com (Pamela Kane) writes:

>OK...Forget the few hours with DEBUG.  A simple INT 21 intercept program 
>points up the bug.  LABEL gets the current directory with INT 21 function 
>47, which does not give drive and root, only path.  This string is fed 
>through the undocumented function 60 to get the fully resolved 
>drive:path.  (This will account for a SUBST or ASSIGNED or JOINED 
>drive.)  

Why does it care if you've used subst or assign or join?  It should use the 
drive as it appears on the surface, not some hidden true name for it.
Sounds to me like someone at MS was just a bit too clever.


Duncan Murdoch
dmurdoch@mast.queensu.ca

Duncan Murdoch (dmurdoch@mast.queensu.ca) wrote:
: In article <2kq5g0$rq@marlin.ssnet.com> panda@marlin.ssnet.com (Pamela Kane) writes:

: >OK...Forget the few hours with DEBUG.  A simple INT 21 intercept program 
: >points up the bug.  LABEL gets the current directory with INT 21 function 
: >47, which does not give drive and root, only path.  This string is fed 
: >through the undocumented function 60 to get the fully resolved 
: >drive:path.  (This will account for a SUBST or ASSIGNED or JOINED 
: >drive.)  

: Why does it care if you've used subst or assign or join?  It should use the 
: drive as it appears on the surface, not some hidden true name for it.
: Sounds to me like someone at MS was just a bit too clever.

What about a Network?  There is no real drive "on the surface."  They did 
the right thing, but failed to take into account all the possibilities.  
Perhaps they should have merely walked the CDS to find and store the 
current drive:path.  You have to be careful when using undocumented DOS 
calls such as INT 21 function 60, even if you wrote it.