* 'fix_depreciation_warning' of https://github.com/bbuchalter/rubyzip:
Use default ruby behavior for Array.join
Remove OUTPUT_FIELD_SEPARATOR-related test behaviors
Set OUTPUT_FIELD_SEPARATOR to nil in test
Prefer OUTPUT_RECORD_SEPARATOR to $\
Prefer OUTPUT_FIELD_SEPARATOR to $,
Rename it to `find_entry` because that is ultimately what is called on
the underlying zip file. Make `FileSystem::File#find_entry` public as it
need to be called from `FileSystem::File::Stat`, so now we can avoid
`__send__`. Neither class is documented anyway, so no harm done there.
Fixed error:
ZipFileTest#test_open_buffer_no_op_does_not_change_file:
Errno::ENOTEMPTY: Directory not empty @ dir_s_rmdir - D:/a/_temp/d20210605-6612-1yi35sp
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/fileutils.rb:1335:in `rmdir'
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/fileutils.rb:1335:in `block in remove_dir1'
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/fileutils.rb:1349:in `platform_support'
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/fileutils.rb:1334:in `remove_dir1'
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/fileutils.rb:1327:in `remove'
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/fileutils.rb:689:in `block in remove_entry'
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/fileutils.rb:1384:in `ensure in postorder_traverse'
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/fileutils.rb:1384:in `postorder_traverse'
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/fileutils.rb:687:in `remove_entry'
C:/hostedtoolcache/windows/Ruby/2.4.10/x64/lib/ruby/2.4.0/tmpdir.rb:101:in `mktmpdir'
D:/a/rubyzip/rubyzip/test/file_test.rb:136:in `test_open_buffer_no_op_does_not_change_file'
Rationale:
File#dup does not behave like what you would expect from #dup on Ruby.
File#dup calls dup(2), which has OS dependant behavoir.
On Windows, calling File#dup seems to cause an extra reference
to an open file, which prevents deleting that file later.
With this commit, we leave out the call to File#dup on Windows.
It is not clear to me that removing this call has no undesired
consequences, but all other existing tests still succeed.
This will enable `InputStream` to be used with external APIs that expect
to be able to query the expected size of data they will receive, such as
S3.
Fixes#451.
Workaround jruby/jruby#6668 until fix is released.
Version 9.2.18.0 is hopefully the version that will fix this, but we can
adjust the version accordingly if not.
Since we are using the default behavior of OUTPUT_FIELD_SEPERATOR
anyway, let's allow Ruby to maange that default for us, so if it should
change in the future, we don't have to change.
Having a specific 'does this instance equal another instance' method is
kind of annoying and breaks a number of things. Most obviously it breaks
comparing to `nil`: `nil.dos_equals(other)` will fail where
`nil == other` does not.
So this commit overrides `<=>` in `Zip::DOSTime` and deprecates
`dos_equals`.
If an input stream has been read from, and left some data in the
internal buffer, then a subsequent `read`, with no amount of bytes to be
read having been specified, will raise an error when comparing to `nil`.
This fix checks that the number of bytes specified in the `read` is not
`nil` before comparing with the size of the internal buffer.
Fixes#461.
From what I can tell this was erroneously copied out of extra_field.rb
during a refactor. It attempts to compare a non-existent Hash that used
to be inherited before the refactor. If this code had been left within
ExtraField it would make more sense, but as it's not needed there either
let's just remove it.
See 20d79feb99 for the refactor.
Previously, only the extra fields stored in the central directory were
being read in. In reality it is often the case that the extra field in
the central directory is just a marker, and the full data is in the
local header. So we need to read both in and merge the two into the
final correct extra field. This merging infrastructure was already
implemented in the extra field code but we never actually read the
local extra fields in until now.
Reading the central directory headers and local entry headers seems
rather fragile, so we can't just read one over the other and hope to end
up with a correctly merged set of extra fields because this breaks other
things. So we need to specifically read the local extra field data and
merge just those bits.
This commit also fixes a couple of tests that were 'broken' by us now
reading extra fields in correctly!
As previously implemented the `uid` and `gid` fields could only ever be
read as 0, because they were being initialized to zero and then
memoization (`@uid ||= uid`) was used to 'save' the new value. Using `nil`
as the initial value for either of these fields breaks so many tests, so I
have fixed this by not using memoization instead. This is safe because it
is only the local extra field that holds these values for this type of
extra field.
Whatever the compression method that is set by the user, if the
compression level is set to 0 (no compression), then the entry should be
STORED. This mimics commandline tool behaviour and matches user
expectations.
Constants for Store and Deflate are already available, so use them. It
might be sensible to remove these local versions, but they do have their
uses as a shortened form.
Remove a load of accessors from the 'public' API by not documenting
them, and remove access to `header_signature` completely.
Also, `Entry#extra` has been created to allow extra fields to be set
correctly after initialization.
This greatly simplifies the creation of `Entry` objects when only a
couple of fields are not set to their defaults, while at the same time
allowing an `Entry` to be fully configured at creation time if
appropriate.
This fundamentally changes the `Entry` API and means that some
convenience methods in `OutputStream` and `File` have needed to be
refactored.
There was some fairly odd stuff going on in `put_next_entry` that
allowed for data within an `Entry` to be overridden and prevented an
`Entry` from being a single point of truth. Fixing this also simplifies
the code within `File` and still passes all tests.
Also, fixing the above means we can stop passing the compression level
around as a parameter and use the value stored in each `Entry` directly.
Let's keep `compression_level` out of the `Entry` public API though as
it only makes sense when writing an `Entry`: there doesn't seem to be an
obvious way to read what level of compression was used when reading an
`Entry` from a zip file.
It looks like it needs to be surfaced in `add` and `get_output_stream`.
The compression level defaults to whatever the global default is unless
it is overridden on opening the Zip::File.
Also needed to reorder some of the requires in the top-level module file
now that we are using defaults in the File class.
Allow an Entry to specify a compression level and pass this down to the
underlying OutputStream infrastructure. OutputStream has been able to
specify a compression level for a while but this has, up until now, only
ever been set to the default.
This fundamentally changes the API so will need a major version bump.
With JRuby implementation deflate would always return empty string
without Zlib::SYNC_FLUSH. That can cause memory problems when large
files are in deflate buffer as whole and red there with finish call at
once.
From the documentation: "...times that are present will appear in the
order indicated, but any combination of times may be omitted. (Creation
time may be present without access time, for example.)"
This fixes the parsing so that the times are read into the correct
fields, according to the flags. Before they were simply assumed to be in
order and all present.
From the documentation: "The time values are in standard Unix signed-long
format, indicating the number of seconds since 1 January 1970 00:00:00."
The three time values were being unpacked with 'VVV', which is unsigned
32-bit, but they should be unpacked with 'l<l<l<': signed-long little
endian.
There has been an option in `Zip::File` (`:restore_times`) for a long
time, but it seems it has never worked. Firstly the actual timestamp of
an added file wasn't being saved, and secondly an extracted file wasn't
having its timestamp set correctly.
This commit fixes both of those issues, and adds tests to make sure.
Robert Haines
Jan-Joost Spanjers
Ariel Zelivansky
Taichi Ishitani
Oleksandr Simonov
Brian Buchalter
Joni Lahtinen
John Lees-Miller
Sebastian Henke