* Fix unarchive with strip-components in extra_opts
When unarchive is given extra_opts to strip all leading directories, it
could end up trying to change the permissions on the root directory.
Tar archives shouldn't contain absolute paths anyways so make sure that
all paths are relative as we handle them.
Fixes#21397
* Fix idempotency for Unix permissions in zip files.
This fix prevents the unarchive module from reporting 'changed' when a zipfile contains items with Unix permissions that differ from the system default.
* Update zip unarchive tests.
Additional tests for the unarchive module with zip files:
- Test file in zip archive with non-default permissions
- Test file added to zip archive with Windows permissions
* Additional fix for mixed win/unix archives.
Turns out my original fix fails under some mixed archives, as setting the umask to zero can be applied to those files. This creates a per-file umask variable, so a mix of permission types don't cause problems.
* CI Checks
CI checks for archives with:
* non default Unix permissions
* Windows permissions
* Workaround for BSD differences.
Using Zipinfo due to lack of support in BSD unzip.
Permissions handling is also different in BSD -- always applies UMASK to file permissions.
* Added checks for creating directories and SSH keys for existing users.
Added fix for missing imports and boilerplate in files modules,
also, removed get_exception calls to match 2.6> exception handling.
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
* Mutually reference Windows and non-Windows modules
To make it easier for Windows or non-Windows users to find the relevant
module information, we are mutually referencing both variants in their
documentation.
We are also adding a special note if a module works on both Windows and
non-Windows targets.
* Mutually reference Windows and non-Windows modules
To make it easier for Windows or non-Windows users to find the relevant
module information, we are mutually referencing both variants in their
documentation.
We are also adding a special note if a module works on both Windows and
non-Windows targets.
* Replace 'look at' with 'use', as requested
ci_complete
Recent Python3 versions require open() to specify binary mode if the data is anything other than text.
Python3: Use int() instead of long() in unarchive
Changes long() to int() for CRC values in the unarchive module. Affects unarchiving of zip files. Since CRC values in zipfile are 32 bits the behaviour should be unchanged even in Python 2.
Changes to the metadata format were approved here:
https://github.com/ansible/proposals/issues/54
* Update documentation to the new metadata format
* Changes to metadata-tool to account for new metadata
* Add GPL license header
* Add upgrade subcommand to upgrade metadata version
* Change default metadata to the new format
* Fix exclusion of non-modules from the metadata report
* Fix ansible-doc for new module metadata
* Exclude metadata version from ansible-doc output
* Fix website docs generation for the new metadata
* Update metadata schema in valiate-modules test
* Update the metadata in all modules to the new version
* Avoid having module documentation links to itself
A lot of modules use M(own_module) in their documentation causing a link
in the documentation to itself.
* Make note more clear now
Since handler.files_in_archive is a list of files coming from
various executables output, that's a bytes list, and we use it
with dest who is a str. So we need to convert that to native
type.
Fixes#4063.
Tar does not use this parameter on extraction (-x) or diff (-d)(the
only two cases where it is passed in unarchive). It only uses it on
creation:
https://www.gnu.org/software/tar/manual/html_section/tar_33.html
Providing `unarchive` with a file mode of `0755` (octal) makes it pass
the argument `--mode 493` (493 = 0755 in decimal) to `tar`, which then
fails while verifying it (because it contains an invalid octal char
'9'). Not passing the parameter to tar solves the issue.
This means we will have to unarchive the complete archive if a single change is found.
Unfortunately we cannot fix this for `unzip`, the only hope is a pure-python reimplementation.
This fixes problems reported in the comments of #3810
* Ensure unicode characters in zip-compressed filenames work correctly
Another corner-case we are fixing hoping it doesn't break anything else.
This fixes:
- The correct encoding of unicode paths internally (so the filenames we scrape from the output and is returned by zipfile match)
- Disable LANG=C for the unzip command (because it breaks the unicode output, unlike on gtar)
* Fix for python3 and other suggestions from @abadger
* Improve the correct handling of gtar and unzip options
Add the option --show-transformed-names when extra_opts is being used
Ignore bogus warnings related to empty filenames
Properly quote _and_ escape filenames for unzip command
Rewrite gtar options and provide run_command with array, not string
This fixes#2480 and #4109.
* Make check-mode work for zip-files
Check-mode was disabled for zip-files since gtar did not support it.
This change enables check-mode support for zip-files, but does skip the task when used with gtar.
(Best of both worlds)
Also remove unused compress_mode variable.
This replaces PR #4401, the changes overlap somewhat so I merged them
When you try to remote unarchive files with the option copy=no the code always fail, as evidenced in issue #4202. That happens because the conditional to check "if remote_src=no or copy=yes" will always be true since the default value of them is remote_src=no and copy=yes.
My modification is only to change the condition from or to and, that way only if both the vars stay with the default value will be true, otherwise you can unarchive remote files.
A capital "S" appears when the the setuid or setgid bit are set but have no effect. Likewise, a capital "T" appears when the sticky bit is set but it has no effect.
* Revert PR #3575 since it causes problems related to exclude patterns
By using a different method for getting archive filelists, and extracting we introduced new problems related to excluding based on gtar patterns.
As a result files that would be excluded by gtar, would still be in the filelist. Implementing our own gtar compatible pattern exclusion mechanism is near to impossible (believe me, we looked at it...). The best way is to look at the original problem and deal with that, and ensure that extraction and filelists are done with the exact same tool and exact same options.
The solution is to decode the octal unicode representation in gtar's output back to unicode. Since gtar has no problem extracting these files in LANG=C, we simply has to compensate for it.
This reverts #3575 and fixes#11348.
* Implement codecs.escape_decode() instead of decode("string_escape") for python3
* A few more sanity checks for detecting unzip output that's not a file entry
Also note that there's a rounding error somewhere in the mtime
comparison code.
* Fix reference to sub-array
* Improve the unzip output scraping
Ensure we capture the complete file (also when it includes spaces).
Drop lines that do not conform (in length) to what we expect (e.g. header/footer).
This fixes#3813
* Fix how split() works
Kassian Sun
Toshio Kuratomi
Dag Wieers
Richlv
chriskarel
Luke Armstrong
Abhijeet Kasurde
Matt Martz
Karl Bergström
Paul Montero
Brian Coca
Tim Rupp
Matt Clay
sirkubax
Brian Coca
Fabio Alessandro Locati
Sam Doran
Michael Scherer
JesseEmond
Lucas Costa Beyeler
Ryan S. Brown
James Cammarata
neo
Jan Fader