## #1483 mkdir -p fails with //server/dir/subdir notation

MSYS
pending
Bug
none
Unknown
False
2013-02-08
2010-10-20
Anonymous
No

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 ## Discussion • Keith Marshall - 2010-11-01 • labels: --> MSYS • assigned_to: nobody --> cstrauss • Keith Marshall - 2010-11-01 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
...
...

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).

• Earnie Boyd - 2010-11-02

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 has been marked as spam.
Undo

You can see all pending comments posted by this user  here

Anonymous - 2010-11-03

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.

• Earnie Boyd - 2010-11-05

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 has been marked as spam.
Undo

You can see all pending comments posted by this user  here

Anonymous - 2010-11-05

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.

• Keith Marshall - 2010-11-05

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.

• Earnie Boyd - 2010-11-05

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 has been marked as spam.
Undo

You can see all pending comments posted by this user  here

Anonymous - 2010-11-08

OK, initally I have a network share

\\superserver\spfdata2\foo

which is empty. Here's a transcript of my session with [comments]

$mkdir '\\superserver\spfdata2\foo\baz' [ This works, directory created ]$ mkdir -p '\\superserver\spfdata2\foo\bar'
[This also works]

$mkdir '\\superserver\spfdata2\foo\baz\dog\cat' mkdir: cannot create directory \\\\superserver\\spfdata2\\foo\\baz\\dog\\cat': No such file or directory [Shouldn't work, it didn't]$ mkdir -p '\\superserver\spfdata2\foo\bar\justin\bieber'
mkdir: cannot create directory \\\\superserver\\spfdata2\\foo\\bar\\justin\\bieber': No such file or directory

[That should work, in that I can make each directory in turn, but it doesn't.]

Last edit: Anonymous 2014-09-26
• Emanuel Elhardt - 2011-01-18

I can confirm this bug as well:
$uname -a MINGW32_NT-5.1 ... 1.0.15(0.47/3/2) 2010-07-06 22:04 i686 Msys bash-3.1$ mkdir --version
mkdir (GNU coreutils) 5.97

any more ideas how to create a directory with its parents using a unc path???

Thank's

• Keith Marshall - 2011-01-21

Shell archive: interim workaround for mkdir bug

• Keith Marshall - 2011-01-21

There is clearly a bug in the current MSYS build of mkdir.exe. Until Cesar or Chuck can get around to resolving it, mkdir -p' just isn't going to work with a UNC path. To work around it, you have two choices -- either map a network drive in place of the UNC share, or build the path one directory at a time from an existing parent, running mkdir without the -p option each time, until the full UNC path is constructed.

As an interim workaround, the latter technique may be automated. I've attached a shell archive to illustrate the mechanism -- run it to install the workaround. It seems to work for me, but as with all MinGW software, it comes with absolutely no guarantees -- if you choose to use it, you do so entirely at your own risk.

• Earnie Boyd - 2013-02-08
• labels: MSYS --> mkdir, UNC paths
• status: open --> pending
• milestone: --> MSYS
• type: --> Bug
• resolution: --> none
• category: --> Unknown
• patch_attached: --> False