[Octave-bug-tracker] [bug #45816] canonicalize_file_name() changed behavior between 3.8.2 and 4.0.0 on windows

[Rik]

Follow-up Comment #20, bug #45816 (project octave):

Great.  I will wait for word from jwe about whether the #include is just
weird, or needs to be changed.

I checked the Cygwin documentation and I see this:


Mapping path names
Introduction

Cygwin supports both POSIX- and Win32-style paths. Directory delimiters may be
either forward slashes or backslashes. Paths using backslashes or starting
with a drive letter are always handled as Win32 paths. POSIX paths must only
use forward slashes as delimiter, otherwise they are treated as Win32 paths
and file access might fail in surprising ways.
Note

The usage of Win32 paths, though possible, is deprecated, since it circumvents
important internal path handling mechanisms. See the section called “Using
native Win32 paths” and the section called “Using the Win32 file API in
Cygwin applications” for more information. 


And the section "Using native Win32 paths" has this


Using native Win32 paths

Using native Win32 paths in Cygwin, while possible, is generally inadvisable.
Those paths circumvent all internal integrity checking and bypass the
information given in the Cygwin mount table.

The following paths are treated as native Win32 paths in Cygwin:

    All paths starting with a drive specifier

      C:\foo
      C:/foo

    All paths containing at least one backslash as path component

      C:/foo/bar\baz/...

    UNC paths using backslashes

      \\server\share\...

When accessing files using native Win32 paths as above, Cygwin uses a default
setting for the mount flags. All paths using DOS notation will be treated as
case insensitive, and permissions are just faked as if the underlying drive is
a FAT drive. This also applies to NTFS and other filesystems which usually are
capable of case sensitivity and storing permissions.


So it seems that it is generally advisable to use the Unix file separator on
Cygwin.

Since this is a regression, I will push this to stable.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45816>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/