[MinGW-notify] [ mingw-Bugs-3091216 ] mkdir -p fails with //server/dir/subdir notation

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #3091216, was opened at 2010-10-20 07:39
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gwowen ()
Assigned to: Cesar Strauss (cstrauss)
Summary: mkdir -p fails with //server/dir/subdir notation

Initial Comment:
If you use UNC with forward slashes to designate network address, then mkdir -p won't create parents when necessary

$ ls //superserver/data/tmp/foo
ls: //superserver/data/tmp/foo: No such file or directory

$  mkdir //superserver/data/tmp/foo
$ ls //superserver/data/tmp/foo

The directory exists on the network resource, which is as expected... 

However if I now do

$ mkdir -p //superserver/data/tmp/foo/bar/baz/shazam

I get no error message, but 
$ ls //superserver/data/tmp/foo/bar/baz/shazam
ls: //superserver/data/tmp/foo/bar/baz/shazam: No such file or directory

In fact, the requested directory hierarchy gets made under the root directory, exactly as if I had a single leading slash, not a double leading slash...

This is MSYS-1.0.11, mkdir --version says: mkdir (GNU coreutils) 5.97

----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2010-11-05 15:04

Message:
I'm glad I documented it! :o  I'm not setup any longer to test it.  I.E. I
don't have a //server to connect to.

Yes, you're correct the / reduction is not going to occur for MSYS runtime
dependent binaries.  Perhaps this is a case where / needs to be converted
to \ before passing it to the windows functions.  Does
\\\\server\\some\\dir work?

NOTE: Depending on the number of indirections you may have to double up
the number of \\.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-11-05 13:04

Message:
Earnie,

My immediate thought was that this was a slash reduction issue, and that
the solution was to specify ///server/path, but I tried it before
responding originally, and IT DIDN'T WORK!  (Specifically, in the case of
mkdir -p; both ls and mkdir without -p are fine with only two initial
slashes).

So, I went back and read the README file again.  It EXPLICITLY documents
the slash reduction effect WHEN PASSING PARAMETERS TO NATIVE WIN32
PROGRAMS; by implication NO SUCH REDUCTION is performed when invoking MSYS
programs.  Thus, I conclude that the //server/path form is correct, (but
confusing), when invoking MSYS programs, while ///server/path is correct
when invoking native programs but INCORRECT when invoking MSYS programs. 
(Of course, it would be much less confusing if ///server/path was always
correct, and the distinction alluded to in the README wasn't actually
made).

So, I concur with the OP: there is a specific bug in mkdir, in that it
misbehaves when -p is specified with a UNC style server path name.  There
is also a potential bug in MSYS generally, in that MSYS programs accept
//server/path, where they would be better to require ///server/path, for
consistency in handling between MSYS and native program invocations.

----------------------------------------------------------------------

Comment By: gwowen ()
Date: 2010-11-05 09:30

Message:
Well OK, but if thats the case, now you've got two bugs: Out of

mkdir ///superserver/spfdata/test
mkdir -p ///superserver/spfdata/test
mkdir -p //superserver/spfdata/test
mkdir //superserver/spfdata/test

only the last one does the right thing.  The first two ('///') fail with 
`///superserver/spfdata/foo': No such host or network path, 

as does "ls ///superserver" and almost every other command I care to try. 

As initially reported, the third one fails silently, and the fourth one
works fine.  

With coreutils-5.97, the triple-slash variant does not seem to be
supported at all.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2010-11-05 07:54

Message:
The solution for passing switches in Microsoft style to "native" windows
programs was a feature to remove one / from multiple // so that the /
wouldn't be translated from POSIX to Windows paths.  So one can easily do
``cmd //c dir'' from the MSYS shell.  But this means that any // will
become / regardless of the purpose of //.  To work around that issue you
simply add one more / to // so that it becomes /// and MSYS will remove one
and pass it on.  The current correct method of specifying the
\\server\some\dir in MSYS is ///server/some/dir regardless of where on the
command line it is used.

I consider that the bug here is that //server/some/dir is working in some
of the cases instead of none of the cases since it really should be
///server/some/dir for any of the cases to work.

----------------------------------------------------------------------

Comment By: gwowen ()
Date: 2010-11-03 02:09

Message:
Thanks for looking at this: earnie, I can see your point, but whatever the
solution, I think the behaviour should be consistent: the parsing of
//foo/bar/baz should not depend on whether I pass the -p switch.  At the
moment, it does.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2010-11-02 08:57

Message:
The // becomes / as a feature of MSYS to help with /C style switches in
Windows.  To use //domain/some/dir you need to add another / so for MSYS
the proper notation for using domains is ///domain/some/dir since multiple
/ removes one / from the string.  In my thinking this is a won't fix but
Cesar may have some idea of doing something different.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2010-11-01 11:42

Message:
Confirmed here:

$ uname -a
MINGW32_NT-6.0 ... 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys

$ mkdir --version
mkdir (GNU coreutils) 5.97
...

$ ls //domain/data/HoneywellManuals
...
ad20110.pdf   ad21110.pdf   ad40110.pdf   ad41110.pdf                   
ad80110.pdf   ad90110.pdf   am03500.pdf   am09501.pdf
...

works for me, but:

$ mkdir -p //domain/data/HoneywellManuals/foo/bar

fails silently, (with no evidence of directory creation anywhere, in my
case).

However:

$ mkdir //domain/data/HoneywellManuals/foo
$ mkdir //domain/data/HoneywellManuals/foo/bar

does work as expected, as does:

$ mkdir -p /w/HoneywellManuals/foo/bar

(W: is a mapped network drive, set up by my network/domain administrator,
to represent //domain/data).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435