bugGNU Octave - Bugs: bug #62888, UNC versus drive letter path...

 
 

bug #62888: UNC versus drive letter path issues on Windows

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Thu 11 Aug 2022 05:42:04 PM UTC
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Need Info Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Open
Release:  * dev Operating System:  * Microsoft Windows
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Sat 10 Sep 2022 06:56:02 PM UTC, comment #8: 

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.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 19 Aug 2022 07:07:55 PM UTC, comment #7: 

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.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 18 Aug 2022 10:34:38 AM UTC, comment #6: 

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

Markus Mützel <mmuetzel>
Project Member
Thu 18 Aug 2022 09:24:16 AM UTC, comment #5: 

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

Philip Nienhuis <philipnienhuis>
Project Member
Thu 18 Aug 2022 06:47:23 AM UTC, comment #4: 

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?

Markus Mützel <mmuetzel>
Project Member
Wed 17 Aug 2022 06:49:52 PM UTC, comment #3: 

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.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 14 Aug 2022 01:19:18 PM UTC, comment #2: 

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

Markus Mützel <mmuetzel>
Project Member
Sun 14 Aug 2022 11:50:39 AM UTC, comment #1: 

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

Markus Mützel <mmuetzel>
Project Member
Thu 11 Aug 2022 05:42:04 PM UTC, original submission:  

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

After deleting ‘putmetingen.xlsx’ in subdir ‘m-files’  that is in the path:

>> gwsstruct2xlsx (gws)
mv: preserving permissions for 'T:/FULL/path/to/projectdir/Data/putmetingen.xlsx': Not supported
ans = 0
>>

So, with UNC paths I get:

  • This

    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;

  • A permission issue, where the path is morpphed into a UNC path;
  • An error seemingly related to unzip not able to unpack an existing archive (Excel .xlsx is really a .zip archive).
  • An error from 'xlsopen' but really emitted by fopen() about not being able to write to a file in the load path.  I'm not sure if that is the expected behavior; i.e., when trying to write to a file in the current directory (not in the path), getting errors related to identically named files in the load path.

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.

Philip Nienhuis <philipnienhuis>
Project Member

 

(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

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    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.

     

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-08-14 mmuetzel CategoryInterpreter Octave Function
    2022-08-14 mmuetzel StatusNone Need Info

    Back to the top


    Powered by Savane 3.9