[Octave-bug-tracker] [bug #62888] UNC versus drive letter path issues on Windows

[Philip Nienhuis]

URL:
  <https://savannah.gnu.org/bugs/?62888>

                 Summary: UNC versus drive letter path issues on Windows
                 Project: GNU Octave
               Submitter: philipnienhuis
               Submitted: Thu 11 Aug 2022 07:42:04 PM CEST
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Unexpected Error or Warning
                  Status: None
             Assigned to: None
         Originator Name: Philip Nienhuis
        Originator Email: 
             Open/Closed: Open
                 Release: dev
         Discussion Lock: Any
        Operating System: Microsoft Windows


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Thu 11 Aug 2022 07:42:04 PM CEST By: Philip Nienhuis <philipnienhuis>
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.








    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62888>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/