Dar archive are binary files, they must be transfered in binary mode when using FTP. This is done in the following way for the ftp command-line client :

ftp <somewhere>
<login>
<password>
bin
put <file>
get <file>
bye

If you transfer an archive (or any other binary file) in ascii mode (the opposite of binary mode), the 8th bit of each byte will be lost and the archive will become impossible to recover (due to the destruction of this information). Be very careful to test your archive after transferring back to you host to be sure you can delete the original file.

In each file property there is not present the name of the owner nor the name of the group owner, but instead are present two numbers, the user ID and the group ID (UID & GID in short). In the /etc/password file theses numbers are associated names and other properties, like the login shell, the home directory, the password (see also /etc/shadow). Thus, when you do a directory list (with the 'ls' command for example or with any GUI program for another example), the listing application used does open each directory, there it finds a list of name and a inode number associated, then the listing program fetchs the inode attributes for each file and looks among other information for the UID and the GID. To be able to display the real user name and group name, the listing application calls a given standard C library call that will do the lookup in /etc/password, eventually NIS system if configured and any other additional system, [this way applications have not to bother with the many system configuration possible, the same API interface is used whatever is the system], then lookup returns the name if it exist and the listing application display for each file found in a directory the attributes and the user name and group name as returned by the system.

As you can see, the user name and group name are not part of any file attribute, but UID and GID *are* instead. Dar is a backup tool mainly, it does preserve at much as possible the files property to be able to restore them as close as possible to their original state. Thus a file saved with UID=3 will be restored with UID=3. The name corresponding the UID 3 may exist or not,  may exist and be the same or may exist and be different, the file will be anyway restored in UID 3.

Thus, when doing backup and restoration of a crashed system you can be confident, the restoration will not interfere with the bootable system you have used to launch dar to restore your disk. Assuming you have UID 1 labeled 'bin' in your real crashed system, but this UID 1 is labeled 'admin' in the boot system, while UID 2 is labeled 'bin' in this boot system, files owned by bin in the system to restore will be restored under UID 1, not UID 2 which is used by the temporary boot system. At that time after restoration still running the from the boot system, if you do a 'ls' you will see that the original files owned by 'bin' are now owned by user 'admin'.

This is really a mirage: in your restoration you will also restore the /etc/password file and other system configuration files (like NIS configuration files if they have been used), then at reboot time on the newly restored real system, the UID 1 will be backed associated to user 'bin' as expected and files originally owned by user bin will now been listed as owned by bin as expected.

If dar had done else, restoring the files owned by 'bin' to the UID corresponding to 'bin', theses files would have been given UID 2 (the one used by the temporary bootable system used to launch dar). But once the real restored system would have been launched, this UID 2 would have become some other user and not 'bin' which is mapped to UID 1 in the restored /etc/password.

Now, if you want to change some UID/GID when moving a set of files from one live system to another system, there is no problem if you are not restoring dar under the 'root' account. Other account than 'root' are usually not allowed to modify UID/GID, thus restored files by dar will have group and user ownership of the dar process, which is the one that has launched dar.

But if you really need to move a directory tree containing a set of files with different ownership and you want to preserve theses different ownership from one live system to another, while the corresponding UID/GID do not match between the two system, dar can still help you:

• Save your directory tree on the source live system
• From the root account in the destination live system do the following:
• restore the archive in a empty directory
• change the UID of files according to the one used by the destination filesystem with the command:

• isolate your encrypted archive to unencrypted 'extracted catalogue': Do not use the -K option while isolating, you will however need to use the -J option to let dar able to read the encrypted archive. Note that still for key protection, you are encouraged to use a DCF (Dar Command File, which  is a plain file with a list of options to be passed to dar) file with restricted permissions and containing the '-J <key>' option to be passed for dar. The dar's -B option would then receive this filename. this will avoid other users of your system to have a chance to read the key you have used for your archives,
  
• add theses extracted catalogue to the dar_manager database of your choice,
• change the name and path of the added catalogue to point to your real encrypted archives (-b and -p options of dar_manager).

1. dar_manager's command-line: simply pass the -e "-K <key>" to dar_manager . Note that this will expose the key twice: on dar_manager's command-line and on dar's command-line.
   
2. dar_manager database: the database can store some constant command to be passed to dar. This is done using the -o option, or the -i option. The -o option exposes the arguments you want to be passed to dar because they are on dar_manager command-line. While the -i option, let you do the same thing but in an interactive manner, this is a better choice. However, if -i option it is a safe way to feed the dar_manager database with the '-K <key>' option to be passed to dar, this option will be received by dar on command-line. Thus still the key will be visible by other users on your same system.
3. The last and best way is to use a DCF file with restrictive permission. This one will receive the '-K <key>' option for dar to be able to read the encrypted archives. And dar_manager will ask dar to read this file thanks to the '-B <filename>' option you will have give either on dar_manager's command-line (-e -B <filename> ...) or from the stored option in the database (-o -B <filename>).