bugGNU Octave - Bugs: bug #43206, gunzip deletes source files

 
 

bug #43206: gunzip deletes source files

Submitted by:  None
Submitted on:  Fri 12 Sep 2014 07:28:42 AM UTC  
 
Category: Octave FunctionSeverity: 3 - Normal
Priority: 3 - LowItem Group: Matlab Compatibility
Status: ConfirmedAssigned to: None
Originator Name: StefanOriginator Email: -unavailable-
Open/Closed: OpenRelease: 3.8.2
Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 19 Dec 2016 07:34:57 PM UTC, comment #10:

Thanks for testing. So the incompatibility still exists and Octave removes the original .gz file while Matlab does not.

Rik <rik5>
Project Administrator
Mon 19 Dec 2016 07:30:46 PM UTC, comment #9:

I have checked with Matlab (R2014b). It doesn't do this.

The result from the final "exist" code line in comment #8 is still 2, and at the end both files still exist.

Hartmut <hardy>
Fri 16 Dec 2016 09:58:37 PM UTC, comment #8:

It mostly works with archives (.tar.gz). This is about individual gzipped files. Start with a file "hello" that contains some basic text like "123".

As you can see from the call to exist, the file "hello.gz" has been removed.

If you have access to Matlab, you could test whether this behavior has changed.

Otherwise, something else needs to be done.

Rik <rik5>
Project Administrator
Fri 16 Dec 2016 07:25:56 PM UTC, comment #7:

This issue might already be FIXED in Octave 4.2.0.

Here is what I did:

  • create two tar archives inside a folder
  • make this folder the current folder of Octave
  • run gunzip('*.gz') in Octave
  • the result seems fine now:
    • the two gz files are BOTH unpacked properly
    • the two original gz files are NOT deleted

This worked fine with both a (self built on Ubuntu 16.04) linux Octave and the (official 32-bit installer on WinXP) mxe-octave.

Or are there any issues of this bug report still open?

Hartmut <hardy>
Tue 07 Oct 2014 09:37:49 PM UTC, comment #6:

The troublesome part is going to be recursive directory processing. Not relying on 'gunzip -r' means having to write a directory traversal tool in the style of find.

Rik <rik5>
Project Administrator
Tue 07 Oct 2014 08:21:32 PM UTC, comment #5:

I think a pipe is cleaner because with the copy, you have to ensure that you are using a good tmp file name, that the copy succeeds. Although disk space is cheap, someone might be working on a relatively full partition that does not have room for the original file, the copy, and the uncompressed extracted contents of the archive. I think it would be better to avoid the unnecessary copy.

John W. Eaton <jwe>
Project Administrator
Tue 07 Oct 2014 07:30:35 PM UTC, comment #4:

Circling back to this issue since I just finished overhauling unpack. What is the Matlab-compatible behavior we are trying to duplicate? Do they definitely keep the original archive?

I think Mike's suggestion is the clean way to do things. However, we could cheat and just do:

This would also work across platforms and is simple to implement. It, does, however, require a copy of an archive file that might be very large. On the other hand, disk storage space is so cheap that it is probably meaningless to optimize here.

Rik <rik5>
Project Administrator
Mon 15 Sep 2014 03:03:57 PM UTC, comment #3:

Gzip only supports --keep in version 1.6 (2013-06-09) and newer unfortunately. It might be better to use stdin piping instead for portability.

On the mailing list, Stefan Reimann wrote:

> Matlab overwrites output file always silently, even if the same file is gunzipped again and there is no option to prevent it from.


Stefan, please comment on the bug tracker, email replies are not sent to the bug report.

Mike Miller <mtmiller>
Project Administrator
Sat 13 Sep 2014 07:37:46 PM UTC, comment #2:

I think you can just add "-k" options in the bzip2 and gzip commands that Octave executes.

What is supposed to happen when output files exist? Does Matlab prevent you from overwriting them, or does it just overwrite silently?

John W. Eaton <jwe>
Project Administrator
Fri 12 Sep 2014 01:15:07 PM UTC, comment #1:

Thanks for your bug report. So it seems bunzip2, gunzip, and unpack need to be updated to preserve the archive file (except for URL downloads to temporary files).

It's best to make distinct bug reports for each issue, please open a separate report for the wildcard problem.

Mike Miller <mtmiller>
Project Administrator
Fri 12 Sep 2014 07:28:42 AM UTC, original submission:

Matlab-Example using wildcard (taken from Matlab R2011b):

% gunzip all *.gz files in the current directory
gunzip('*.gz');

Furthermore Matlab does not delete *.gz source files as Octave does!!! ==> very dangerous if this Octave behaviour is not known to the user

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by hardy (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 16 Dec 2016 09:58:37 PM UTCrik5Priority5 - Normal=>3 - Low
    Fri 12 Sep 2014 01:15:07 PM UTCmtmillerStatusNone=>Confirmed
      Operating SystemMicrosoft Windows=>Any
      Summarygunzip deletes source files and doesn\'t accept wildcards=>gunzip deletes source files

    Back to the top


    Powered by Savane 3.1-cleanup1