[Octave-bug-tracker] [bug #58547] gzip() does not handle relative paths in first argument correctly

[anonymous]

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

                 Summary: gzip() does not handle relative paths in first
argument correctly
                 Project: GNU Octave
            Submitted by: None
            Submitted on: Thu 11 Jun 2020 10:08:25 PM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Unexpected Error
                  Status: None
             Assigned to: None
         Originator Name: Harold Gutch
        Originator Email: 
             Open/Closed: Open
                 Release: 5.2.0
         Discussion Lock: Any
        Operating System: BSD

    _______________________________________________________

Details:

(For the sake of completeness, this all this is on FreeBSD 11.3-STABLE on
amd64 with Octave compiled manually, i.e., *not* from the FreeBSD ports
collection)

When calling gzip as

gzip("foo/bar", "outdir")

the code will try to store the output of the gzip operation in the file 
outdir/foo/bar.gz  .  An example where this happens is if you call

pkg build builddir image-1.0.0.tar.gz

at the end of the build, after tar'ing up the build.  If the first parameter
instead is the full path (  "/path/to/foo/bar"  ) or a relative path starting
with  .  or  ..  it tries to store the output in  outdir/bar.gz  , as
expected.

The reason for this is that  libinterp/dldfcn/gzip.cc  around line 556 calls 
sys::env::base_pathname()  which (in l. 369 of  liboctave/system/oct-env.cc  )
first calls  do_rooted_relative_pathname() -nomarkup+ .  That tests if the
parameter is one of  .  ,  ..  , or if it starts with  ./  or  ../  but it
does not test for other types of relative paths (like  foo/bar  ).  It appears
to me this is intentional and should indeed *not* return True for a "normal"
relative pathname, and thus gzip() should not go down this path.

This patch here seems to fix the issue for me by determining the basename
manually in gzip.cc instead of calling base_pathname():


--- octave-5.2.0/libinterp/dldfcn/gzip.cc.orig  2020-01-28 02:57:35.000000000
+0100
+++ octave-5.2.0/libinterp/dldfcn/gzip.cc       2020-06-11 23:14:28.226471000
+0200
@@ -553,7 +553,9 @@
     const std::function<std::string(const std::string&)> mk_dest_path
       = [&out_dir, &ext] (const std::string& source_path) -> std::string
       {
-        const std::string basename = sys::env::base_pathname (source_path);
+        size_t pos = source_path.find_last_of (sys::file_ops::dir_sep_str
());
+        const std::string basename = (pos == std::string::npos ? source_path
:
+                                      source_path.substr (pos+1));
         return sys::file_ops::concat (out_dir, basename + ext);
       };



(this is mildly inspired by ~l.8598 of  libinterp/parse-tree/oct-parse.cc  ).




    _______________________________________________________

Reply to this item at:

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

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