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.
|
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.
|
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.
|
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?
|
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.
|
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.
|
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.
|
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.
|
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?
|
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.
|
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
|