octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #36677] canonicalize_file_name: inconsistent b


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #36677] canonicalize_file_name: inconsistent behavior for non-existing files
Date: Thu, 30 Aug 2012 22:49:53 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6

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

"...begins with a drive letter..." = probably same as ispc().
Anyway that wouldn't make much difference as the second & third examples in
the 1st post show. It would only solve part of the issue.

The issue is that a general mechanism is needed that also returns the full
path of target dirs for non-existent files. Say I'm in /home/philip and I want
to create a file in /tmp. Entering "../../tmp/newfile.fil" should return
/tmp/newfile.fil.

For the same token I could say that the GNU behavior of canonicalize_file_name
is broken.

Anyway some behavior on Windows. With 3.6.2 MSVC2010:
(we're in X:\ = root of drive X:)


octave-3.6.2.exe:1> cd x:\
octave-3.6.2.exe:2> pwd
ans = x:\
octave-3.6.2.exe:3> filename = '../../../tmp/notfound.fil'
filename = ../../../tmp/notfound.fil
octave-3.6.2.exe:4> make_absolute_filename (filename)
ans = xtmp/notfound.fil        ## Faulty
octave-3.6.2.exe:5> canonicalize_file_name (filename)
ans = x:\tmp\notfound.fil      ## Correct
octave-3.6.2.exe:6>


so make_absolute_filename does return info (but faulty).
But now in subdir x:\octave\octave-3.7.x\bin:


octave-3.6.2.exe:7> pwd
ans = x:\octave\octave-3.7.x\bin
octave-3.6.2.exe:8> filename = '../../../tmp/notfound.fil'
filename = ../../../tmp/notfound.fil
octave-3.6.2.exe:9> canonicalize_file_name (filename)
ans = x:\tmp\notfound.fil      ## Correct
octave-3.6.2.exe:10> make_absolute_filename (filename)
ans = x:\tmp/notfound.fil      ## Correct
octave-3.6.2.exe:11>


...so there's a bug too in the sense that make_absolute_filename doesn't note
that the ..\..\.. series descends below the "root level".
Canonicalize_file_name seems robust (but one could argue that it incorrectly
returns correct or rather expected info).

I'd better sort this out in more detail.....
Are there any tests for canonicalize_file_name and make_absolute_filename in
the sources? Do they cover this?

And regarding gnulib: 
what is the gnulib-defined behavior of make_absolute_filename?

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]