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

MSYS
pending
Cesar Strauss
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
    Keith Marshall
    2010-11-01

    • labels: --> MSYS
    • assigned_to: nobody --> cstrauss
     
  • Keith Marshall
    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
    ...
    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).

     
  • Earnie Boyd
    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.

     

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

     

  • 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
    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
    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 \\.

     

  • 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
  • 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
    Keith Marshall
    2011-01-21

    Shell archive: interim workaround for mkdir bug

     
    Attachments
  • Keith Marshall
    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
    Earnie Boyd
    2013-02-08

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