[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #62888] UNC versus drive letter path issues on
From: |
Philip Nienhuis |
Subject: |
[Octave-bug-tracker] [bug #62888] UNC versus drive letter path issues on Windows |
Date: |
Thu, 11 Aug 2022 13:42:05 -0400 (EDT) |
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/
- [Octave-bug-tracker] [bug #62888] UNC versus drive letter path issues on Windows,
Philip Nienhuis <=