[Octave-bug-tracker] [bug #64462] fileparts.m mangles relative paths on Windows drives

[Philip Nienhuis]

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

                 Summary: fileparts.m mangles relative paths on Windows drives
                   Group: GNU Octave
               Submitter: philipnienhuis
               Submitted: Sun 23 Jul 2023 10:48:15 PM CEST
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: Philip Nienhuis
        Originator Email: 
             Open/Closed: Open
                 Release: dev
         Discussion Lock: Any
        Operating System: Microsoft Windows
           Fixed Release: None
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sun 23 Jul 2023 10:48:15 PM CEST By: Philip Nienhuis <philipnienhuis>
A Windows-specific issue. Short way to reproduce:

>> [a, b, c] = fileparts ('c:fntests.log')
a =
b = c:fntests
c = .log

where the actual path ('c:') is somewhere on the *current directory* on drive
C: (not the iroot per se). Note: It is a relative path on that drive.
The bug is that the fileparts function happily absorbs the drive letter and
colon into the filename (output arg #2) rather than the directory (output arg
#1). If the resulting filename is used later on, errors will result.

Now, c:fntests.log is a perfectly valid filename on Windows. More to read
here:
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
and especially the stanza on that page under the heading 'Fully Qualified vs.
Relative Paths':
"If a file name begins with only a disk designator but not the backslash after
the colon, it is interpreted as a relative path to the current directory on
the drive with the specified letter."
While that web page URL suggests it refers to 32-bit Windows, AFAICS this
concept is still working on 64-bit Windows as well. E.g. Powershell can still
work with relative paths on other drive (-letters); although it does silently
insert a backslash (filesep) after the colon if you feed it a filename like
'f:somefile.txt'.

Filenames like 'C:somefile.ext' are not accepted when entered verbatim in the
Open File dialog panes of Windows GUI programs.

I'm unsure about the best way to tackle this. IMO the best way would be to
"properly" move the drive letter+colon and return it in output arg #1, cf. a
patch I'll upload once I have a bug number. Although maybe the path part isn't
that much usable, at least the actual filename will be parsed correctly. But
fileparts.m doesn't check for validity/existence of its output anyway.








    _______________________________________________________

Reply to this item at:

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

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