Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Retaining file permissions while copying between Unix systems

10 views
Skip to first unread message

Tuxedo

unread,
Sep 18, 2018, 4:03:14 AM9/18/18
to
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

Casper H.S. Dik

unread,
Sep 18, 2018, 4:21:22 AM9/18/18
to
Tuxedo <tux...@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

Helmut Waitzmann

unread,
Sep 18, 2018, 8:51:24 AM9/18/18
to
Casper H.S. Dik <Caspe...@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.
0 new messages