Add a New Comment (Rich Markup)
Comment Type & Canned Response: None None > Multiple Canned Responses Fixed in development Crash with no stack trace Already fixed in newer version Fixed in stable Bad description Bad description and crash Bad stack trace Obsolete version Duplicate and not fixed Duplicate and needs more info Duplicate and fixed Need info and old
( Jump to the original submission )
OK I checked (some days ago, had no time to report back until now). Indeed, the messages come from upstream (both CMD.exe (Windows) and mv.exe (MSYS)) so there's little we can do.
OK, next Tuesday I might have time for that. Maybe just firing off the relevant commands in those functions is quicker, I'll have a look.
If the messages come from "upstream" (as I suspect they do) I suppose there's little we can do.
> Or do you want me to step through those?
Exactly.
> somewhere they call MSYS applications and I suppose that's where it happens, not in Octave code.
They should be doing that for me, too. Yet I do not see these warnings here.
> I don't see that CMD.exe warning here. Could you please try and step through the code to see which command triggers that warning for you?
I wrote that already, unzip and movefile. Or do you want me to step through those? I don't think that's needed, somewhere they call MSYS applications and I suppose that's where it happens, not in Octave code.
I pushed the change from comment #2 (plus a comment) to the stable branch: https://hg.savannah.gnu.org/hgweb/octave/rev/6bcc5e6d77fe
I don't see that CMD.exe warning here. Could you please try and step through the code to see which command triggers that warning for you?
That patch seem to work :-)
I still get the messages:
<Long UNC path in the browser pane which is the 'pwd'> CMD.EXE was started with the above path as current directory. UNC paths are not supported. Defaulting to Windows directory.
from unzip.m, and movefile emits the message:
mv: preserving permissions for '<some_UNC_path/somefile>': Not supported.
Yet everything seems to work as designed, AFAICS, but if that is really true I find those messages unduly alarming and IMO these should be silenced.
(FYI I tried to write to a spreadsheet file using <xlsopen - oct2xls - xlsclose>)
In my comment #0 there's another ?bug? that I'll report separately, with fopen() getting confused by a data file in the load path if no full path name was supplied. (Quite confusing for unsuspecting users.) Yet I couldn't reach Savannah and I still get no emails from the bug tracker so I'll wait until Savannah has been fixed with that bug report.
I found something that might be a reproducer:
unzip ('\\server\share\folder\file.zip');
That gives a similar error to the one you showed:
unzip: cannot find or open \server\share\folder\file.zip, \server\share\folder\file.zip.zip or \server\share\folder\file.zip.ZIP.
Note the singular backslash at the start of the paths in the error message.
With this change, the file unzips for me without error message:
diff -r 0a2bf14dd400 scripts/miscellaneous/unpack.m --- a/scripts/miscellaneous/unpack.m Sat Aug 13 16:45:48 2022 -0700 +++ b/scripts/miscellaneous/unpack.m Sun Aug 14 15:11:41 2022 +0200 @@ -271,6 +277,9 @@ unwind_protect unsetenv ("TAR_OPTIONS"); cd (dir); + if (ispc ()) + file = strrep (file, '\', '\\'); + endif [status, output] = system (sprintf ([command " 2>&1"], file)); unwind_protect_cleanup cd (origdir);
It looks like the backslashes in the path need to be escaped. (At least, the double backslash at the start. But it doesn't seem to hurt to escape all of them...)
Does that change fix the issues you are seeing, too? (At least, some of them?)
I'm not able to reproduce this with the information provided so far.
Could you please try to narrow down which functions are causing the actual bugs? (`unzip` for a file on a mapped network drive seems to be working for me. It also doesn't involve starting `CMD.exe` for me. So, there is probably some other condition that isn't met for me that is necessary to reproduce this. Or is it another function that is causing this?)
It would be nice if you could find a minimal example that reproduces this (and that doesn't depend on functions like `gwsstruct2xlsx` that I can't see).
USING UNC PATHS: ================
Saving a file into UNC path in the path (where that subdir is the working directory):
>> gwsstruct2xlsx (gws) ## some script writing to default file 'putmetingen.xlsx' '\\<server>.company.local\FULL$\path\to\projectdir\scripts\m-files' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. mv: preserving permissions for '//<server>.company.local/FULL$/path/to/projectdir/Data/scripts/m-files/putmetingen.xlsx': Not supported ans = 0 >>
After moving to a subdir not in the path through browser pane
>> gwsstruct2xlsx (gws) '\\<server>.company.local\FULL$\path\to\projectdir\Data' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. unzip: cannot find or open putmetingen.xlsx, putmetingen.xlsx.zip or putmetingen.xlsx.ZIP. xlsopen: file putmetingen.xlsx couldn't be unpacked. Is it the proper file format? warning: UnZip failed with error 9 Output: error: warning: STATE structure must have fields 'identifier' and 'state' error: called from __OCT_spsh_open__ at line 72 column 7 xlsopen at line 389 column 35 gwsstruct2xlsx at line 12 column 7 >>
After deleting ‘putmetingen.xlsx’ in subdir ‘m-files’ that is in the path:
>> gwsstruct2xlsx (gws) '\\<server>.company.local\FULL$\path\to\projectdir\Data' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. mv: preserving permissions for '//<server>.company.local/FULL$/path/to/projectdir/Data/putmetingen.xlsx': Not supported ans = 0 >>
USING ONLY DRIVE LETTER PATHS: ==============================
Saving file into drive letter path in the path (where that subdir is the working directory):
>> gwsstruct2xlsx (gws) mv: preserving permissions for 'T:/FULL/path/to/projectdir/Data/putmetingen.xlsx': Not supported ans = 0 >>
Then, moving to a subdir not in the path through browser pane
>> gwsstruct2xlsx (gws) warning: fopen: '\\<server>.company.local\FULL$\path\to\projectdir\scripts\m-files\putmetingen.xlsx' found by searching load path warning: called from xlsopen at line 292 column 11 gwsstruct2xlsx at line 12 column 7 error: xlsopen: write mode requested but file putmetingen.xlsx is not writable >>
So, with UNC paths I get:
CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory.
which comes from somewhere but is merely cosmetic;
As regards the permission errors in case of drive letter paths usage, I can imagine that users wouldn't immediately recognize the actual drive letter path, although IMO that shouldn't be too hard :-) Yet it can be unexpected.
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only project members can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 2 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.9