[Octave-bug-tracker] [bug #57664] dir() function folder element is empty for Windows UNC network-based files

[Mike Miller]

Follow-up Comment #7, bug #57664 (project octave):

The 'canonicalize_file_name' function is great when you want to get the real
absolute path of a file that actually exists as a real local file. If the file
doesn't exist, the return value is empty. So this works for any absolute or
relative file name specification, for example '.', '..', '/tmp/foo/bar',
'../images', 'C:\Files\doc.txt', '\Programs\one\two', and so on.

As I understand it, UNC paths are really closer to URLs than to file names.
That all Windows file I/O functions understand how to resolve and access UNC
paths is great, makes it easy on programs. But it's the same as a path like
'host:/some/file' on a Unix-like system, it's a network resource that needs to
be fetched from elsewhere, and 'canonicalize_file_name' won't work on these
types of paths either.

So my opinion is that 'canonicalize_file_name' is working correctly, it should
return an empty string when given a UNC path specifier, just like a URL or a
host:file specifier.

If you want the 'dir' function to work correctly on UNC names, which I agree
it should, then 'canonicalize_file_name' should be skipped, either always or
only in the case of UNC names.

    _______________________________________________________

Reply to this item at:

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

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