• Retaining file permissions while copying between Unix systems

    From Tuxedo@21:1/5 to All on Tue Sep 18 09:58:57 2018
    Hello,

    In copying a directory which contains files and sub-directories and symlinks from one system to another, to retain symlinks as symlinks, I usually enter
    the directory on the sending system and extract it on the receiving system
    as follows:

    tar cf - * | ssh user@host '(cd /path/to/directory;tar xf - )'

    File permissions are mostly kept on the receiving system as their originals. For example, when in the sending system there's a file:

    -rwxr-xr-x 1 tuxedo tuxedo 9126 Sep 16 09:56 hello.cgi

    ... it ends up in the same way on the target system:

    -rwxr-xr-x 1 tuxedo users 9126 Sep 16 09:56 hello.cgi

    But where there's a file (or directory) with 777 permissions on the sending system, as:
    -rwxrwxrwx 1 tuxedo tuxedo 3264 Sep 18 08:40 log.txt

    ... its group and world permissions on the receiving system do not become writeable:
    -rwxr-xr-x 1 tuxedo users 3264 Sep 18 08:40 log.txt

    There is no group named tuxedo on the receiving system, but even if I create one and make tuxedo a member of it and then redo the tar/ssh procedure, the write file permissions are still missing on the receiving system.

    While there's no problem to fix these file permissions manually on the receiving system, it could be better automatically.

    How can this be done and why do group and world permissions end up different
    on the receiving system?

    Many thanks,
    Tuxedo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Casper H.S. Dik@21:1/5 to Tuxedo on Tue Sep 18 08:21:20 2018
    Tuxedo <tuxedo@mailinator.com> writes:

    In copying a directory which contains files and sub-directories and symlinks >from one system to another, to retain symlinks as symlinks, I usually enter >the directory on the sending system and extract it on the receiving system
    as follows:

    tar cf - * | ssh user@host '(cd /path/to/directory;tar xf - )'

    File permissions are mostly kept on the receiving system as their originals. >For example, when in the sending system there's a file:

    You want to use "p" when extracting.

    tar cf - * | ssh user@host '(cd /path/to/directory;tar xpf - )'


    Generally, tar will create a file with the permissions in the archive,
    however the system will apply the umask (likely 022) and apply that so
    a file mode 777 will be extracted in mode 755.

    With "-p" it should take the original modes.


    Casper

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helmut Waitzmann@21:1/5 to All on Tue Sep 18 14:51:21 2018
    Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM>:

    You want to use "p" when extracting.

    tar cf - * | ssh user@host '(cd /path/to/directory;tar xpf - )'


    Generally, tar will create a file with the permissions in the archive, >however the system will apply the umask (likely 022) and apply that so
    a file mode 777 will be extracted in mode 755.

    Yes, but I've seen a version of GNU tar, which explicitly
    substracts the umask from the permissions in the archive and
    supplies the result to the “mode” parameter of the “creat” or “open” system call.

    The difference can be seen, when extracting to a directory, which
    has got a default access control list: If there is a default
    access control list, the operating system ignores the umask, when
    creating inodes (files or directories), but uses the default access
    control list to limit the effect of the “mode” parameter.

    With "-p" it should take the original modes.

    Yes. That's true, even if there is a default access control iist:
    When given the “-p” option, “tar” explicitly calls the “chmod” system call after having extracted an archive member. As the
    “chmod” system call is not affected by a default access control
    list, “tar” will set the permissions as recorded in the archive,
    when given the “-p” option.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)