search for: dgbaley27

Hello, I would like to specify ports on both hosts to copy files between two remote computeres. Is there any way to do this with scp? The -P flag seems to apply to the port on the second host only. Regards, Miguel

Does anyone have a good distributed backup strategy? I've been revising mine for a year or so now and always realize there's some hole or another in it. I get the feeling to do it exactly the way I want it needs to be complex, but I'm looking for something elegant. My data consists of some of these representative folders: .mozilla Documents Pictures .ssh Music bin And these

I've noticed in 5.4p1 and 5.5p1 that the man page for ssh-agent is misformatted when using --with-mantype=man. In DESCRIPTION, all text after -t life is indented. The line that begins "If a commandline is given..." looks as if it's part of the -t option.

I think a modifier for filter rules that inhibits the --backup option for the particular line might be useful. for example I could have --filter='H,nb /.mozilla/firefox/xxxxx.default/Cache' or I could have --filter'+ /Documents' --filter'+,nb /.mozilla' (So my documents will be backed up to --backup-dir but my firefox profile will not)

Subject should be enough: are hardlinks supported when rsyncing over ssh? I know that I cannot do anything with hardlinks if I'm using SSHFS over FUSE, I was wondering if rsync is plagued by the same problem. Matt

I like the behavior of first doing: cp -al /backup/old /backup/new rsync /source /backup/new This way permissions will be updates throughout all snapshots (I really don't want multiple copies of my entire music collection if I decide to make all songs group readable... etc) Has anyone come up with a way to do this using --link-dest? Matt

Is it possible to set the permissions on the destination side? As I understand it, --chmod just pretends certain permissions are coming from the sending side. I'd like to be able to set permissions to readonly in the destination while coming from a --copy/link-dest which may more may not have had it's permissions changed.

Greetings All, I've been thinking about the current behavior of the --link-dest=DIR option. In the absence of --delete, ALL members of DIR should be linked to the destination (aside from those that are changed). If not, there should at least be a --no-link-dest-delete option. (This latter option might be better to avoid disrupting the behavior of current rsync commands) My rational: This