From: SF/projects/mingw n. l. <min...@li...> - 2010-11-08 10:03:24
|
Bugs item #3091216, was opened at 2010-10-20 11:39 Message generated for change (Comment added) made by 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: gwowen () Date: 2010-11-08 10:03 Message: 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.] ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2010-11-05 19: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 17: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 13: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 11: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 06: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 12: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 15: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 |