Please describe the problem:
When I copied a folder across my LAN using Nautilus and the FTP connector, the
+x permissions got stripped from the executables.


Steps to reproduce:
1. Select the panel menu Places -> Connect to server.
2. Choose the FTP with login method, and fill out the form.
3. Double click on the desktop icon to open a Nautilus view of the remote folder.
4. Find an executable file, copy it across, then right click on it's icon and
select Properties.



Actual results:
I observe that the +x permission bits are no longer present.

Expected results:
The permission bits should remain the same as on the server.

Does this happen every time?
Yes.

Other information:
I tested with the command line 'ftp' program, and found that it also has
stripped the +x permission bits. 'ncftp' also strips them.  On the remote end,
inside of the ftp client, when I execute 'ls -l', the x bits are there:

-rwxr-xr-x    1 1000     1000        42645 Feb 23 22:34 eclipse

In either ftp client, I see the identical listing.  The server is
vsftpd-2.0.4-0ubuntu4.  I do not know if the output from 'ls' is the same for
all servers.  If it is -- and I imagine that most of them will produce output
like that of '/bin/ls -l' -- then that listing output could be screen-scraped
similar to how Emacs 'dired' does it, and the information used to recreate the
permission settings on the recieving end of the link.

The 'sftp://' method does preserve permission settings.  It would be nice if, at
the very least, Nautilus could provide a warning about file permission changes.

When I want to copy a lot of files across the LAN, I'll open a terminal, make
two tabs, then log into the remote host in one of them.  On the receiving end,
I'll run 'nc -p 4000 -l | tar xpf -', and then on the sending end, I'll run 'tar
xpf - dir_of_files/ | nc recvhost 4000'.  That's a LOT faster than using
Nautilus FTP, which is faster than SSH which adds compression and encryption
overhead to the upper layer protocol overhead.  With 'nc' (netcat), it's pure
TCP and very quick.

The drawback of 'tar' is that it does not preserve file ACL or XATTR
information, though perhaps that data is not generally relevant for a transfered
file tree; I think that at times it is, but most of the time it's not.  It could
even be that only some of that information is wanted on the recieving end.

The Eiciel plugin for Nautilus has a very nice ACL and XATTR editor, by the way.  

I wonder if 'libdar' could be put to use for transfers that maintain XATTR data?