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.
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.
StringIO objects created within File.open_buffer were not being switched into
binmode, but those passed in were. Fix this inconsistency and add a test.
Things are now more carefully set up, and if a buffer is passed in which
represents a file that already exists then this is taken into account. All
initialization is now done in File.new, rather than being split between there
and File.open_buffer.
This has also needed a bit of a re-write of Zip::File.initialize. I've tried to
bring some logic to it as a result, and have added comments to explain what is
now happening.
Make the internal @create varible more consistent and actually match the
documentation.
Zip::File::CREATE is now true, rather than 1.
A new test is added to check if passing 1 in still works to ensure backwards
compatibility.
This fixes#294 in what I hope is a more sensible way than trying to mess with
umasks, etc, directly.
Temporary files were being created with 0600 permissions and then being set to
different permissions, based on umask, etc, afterwards. I don't know what the
rationale for this was, but there were errors in the umask calculations when
moving from the temporary file to the intended end result.
Instead of inheriting the permissions from the tmp directory, new files should
have permissions that reflect the defaults on the system taking umask into
account.
It seems that (unix) permissions of 666 - umask are as close to a standard as
anything [1] and that 'touch' uses this. On Windows it seems sensible to just
use 644 directly [2].
[1] http://unix.stackexchange.com/a/102080
[2] http://ruby-doc.org/core-1.9.3/File.html
Robert Haines
Taichi Ishitani
Jan-Joost Spanjers
Phil
Takumasa Ochi
mwlang
Mike Naberezny
Alexander Simonov
Seth Kingsley
Claire Pitman
Victor Costan
Pavel Lobashov
Vít Ondruch