New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tar export fails on FreeBSD: --xform not supported #2389

davidjb opened this Issue Jan 5, 2019 · 4 comments


None yet
2 participants
Copy link

davidjb commented Jan 5, 2019

Describe Your Environment

  • Version of ZoneMinder: v1.32.3
  • How you installed ZoneMinder pkg install zoneminder
  • Full name and version of OS: FreeBSD 11.2

Describe the bug
Tar export fails because the --xform option isn't supported. BSD's tar has the -s option which is almost the same (suggestion below)

To Reproduce
Steps to reproduce the behavior:

  1. Go to Console
  2. Click on an event count
  3. Check box of several events to export
  4. Click Download Video
  5. Choose tar as export format
  6. Click Generate Download
  7. Error occurs, see below for details.

Expected behavior
Tar export to work

Debug Logs

Command 'nice -10 tar --create --gzip --file='/var/tmp/zm/zmExport.tar.gz' --files-from='/var/tmp/zm/zmFileList.txt' --xform='s#^.+/##x'' returned with status 1

Trying to run this command directly shows that --xform is not supported on BSD tar:

$ nice -10 tar --create --gzip --file='/var/tmp/zm/zmExport.tar.gz' --files-from='/var/tmp/zm/zmFileList.txt' --xform='s#^.+/##x'
tar: Option --xform=s#^.+/##x is not supported
  List:    tar -tf <archive-filename>
  Extract: tar -xf <archive-filename>
  Create:  tar -cf <archive-filename> [filenames...]
  Help:    tar --help

The solution is to use -s '#^.*/##' on BSD-derived tar to do the same path replacement rather than --xform='s#^.+/##x' which works for GNU tar. Doing this makes the manual run of the command succeed, so seemingly that's all ZM would need to do to support BSD-based platforms here.


This comment has been minimized.

Copy link

welcome bot commented Jan 5, 2019

Thanks for opening your first issue here! Just a reminder, this forum is for Bug Reports only. Be sure to follow the issue template!


This comment has been minimized.

Copy link

abishai commented Jan 9, 2019

While I confirm the issue, -s in GNU tar is for

       -s, --preserve-order, --same-order
              Sort names to extract to match archive

We can

  • make ZM depend on gtar
  • patch port
  • patch ZM

This comment has been minimized.

Copy link

davidjb commented Jan 9, 2019

@abishai To clarify, what I was suggesting was to support both GNU and BSD tar by testing for OS and using different command flags accordingly. If you depend on gtar, then you're going to end up with a conditional if statement anyway (eg if gtar exists use it else use tar...) so testing on OS or parsing tar --version would avoid the need for another dependency & modifying the port.

Examples from tar --version:

FreeBSD $ tar --version
bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.2.3 bz2lib/1.0.6

Mac $ tar --version
bsdtar 2.8.3 - libarchive 2.8.3

Debian $ tar --version
tar (GNU tar) 1.29
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

This comment has been minimized.

Copy link

abishai commented Jan 10, 2019

Parsing --version is better, we can handle all BSDs and Mac. Not sure if Linux can have BSD tar, but in this possible case we can handle it as well.
I believe I've seen the same method in ansible unpack module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment