[Bug 8119] New: New feature: adapt behavior thanks to extended attributes (xattr)
https://bugzilla.samba.org/show_bug.cgi?id=8119 Summary: New feature: adapt behavior thanks to extended attributes (xattr) Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: way...@samba.org ReportedBy: ymarti...@free.fr QAContact: rsync...@samba.org I would like rsync to support the xattr user.xdg.robots.backup described at http://www.freedesktop.org/wiki/CommonExtendedAttributes If rsync runs with an option --xattr-backup-flag=user.xdg.robots.backup it should skip directories and files with that xattr set to false. So that a user can decide what to exclude from backup without avoid to refer directories into an exclusion file list. I think it is also a good idea to emit a warning when such files/directories are excluded. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: remove-send-files, thanks and question
On Sat, Mar 04, 2006 at 07:45:26PM +, [EMAIL PROTECTED] wrote: So these files will surely not removed, because they are not sent. Ouch, that is not very nice of rsync, is it? The only simple suggestion I can think of is to use -I so that rsync will update even identical files (it will do an efficient update that doesn't send any literal data) and will thus delete all the files in the transfer. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
remove-send-files, thanks and question
First remove-send-files is improved in the actual version and really works better for me, removing is now more in time. In my case I have a buggy wireless cconnection and rsyncing over night in a loop, until rsync return 0, because often the pipe connection gets broken. After a complete success rsync there are files left on the sender, because they where transfered right before loosing connection and not transfered#again, because the file already exists on the next loop on the receivers side. So these files will surely not removed, b ecause they are not send. Can I do something like delete-existing to delete files on the sender that are equal on the receiver? Thanks in advance, Daniel Laffien [AMIGA - because life is too short for boring computers] -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Thanks
Heya just wanted to say thanks, Audra -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Thanks for an excellent rsync!
I had occasion this morning to apply rsync to another task. As usual, the docs were informative, the functionality I needed was easily supported, and rsync worked like a charm. Of course, all this is the result of a lot of hard work by the rsync developers, especially Wayne. I decided it would be good to publicly acknowledge this, lest we all take it for granted. To summarize, from rsync we get: - an indispensable tool - thorough documentation - extremely fast responses to bug reports - a rich feature set - continual improvement with new features and performance enhancements - a commitment to backward-compatibility - a commitment to security - excellent tech support, even for dumb questions - a professional release cycle - maintenance of auxiliary patches - and much more, (feel free to mention what I've left off) And, unbelievably, most of us get all this FOR FREE! For these reasons and more, rsync remains outstanding in the wide field of free and open source software. A heartfelt thanks goes to Wayne, Tridge, and all of the rsync developers. -chris -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
thanks for rsync
Thanks a million for rsync! Sincerely, Jeff Croft jdcroft at best.com -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Ask for help with a chdir failed, thanks!
I want to use rsync2.6.0 in fedora core 1.0. And I install it by configure --with-rsh=rsh;make;make install.But when I run it as follow: bash$ rsync -avz 192.168.3.23::rsync ./ @ERROR: chdir failed rsync: connection unexpectedly closed (33 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(165) What can I do to fix the problem? Thanks a lot! /etc/rsyncd.conf file in 192.168.3.23 as follow uid = nobody gid = nobody max connections = 4 pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock log file = /var/log/rsyncd.log [rsync] uid = nobody gid = nobody path = /home/huaz/rsync-2.6.0/ comment = For test use chroot = no ignore errors read only = yes list = no #auth users = #hosts allow = #secrets file = -- - Hua Zhen Dept. of Technology and Development, Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) No.16-5, Guangzhou Rd., Nanjing, P.R.China PHONE: +86+25-86630523-583 FAX: +86+25-83317685 Mail: [EMAIL PROTECTED] - -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
THANKS
Thank you for your message. A member of staff will respond shortly -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Trouble with password (daemon mode) Thanks, trouble solved.
Hello Dennis, Tuesday, October 21, 2003, 1:32:25 AM, you wrote: DC I running rsync in daemon mode (rsync --daemon) DC Everything seems to work well until I try to protect item with DC password. Thanks, the problem was in rights on file rsyncd.secrets - it was world readable while option strict was set to true by default. -- Best regards, Dennismailto:[EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Proper --exclude= syntax? -- thanks!
--- jw schultz [EMAIL PROTECTED] wrote: On Wed, Jan 08, 2003 at 02:15:13PM -0800, Dan Kressin wrote: I'm currently syncing the home directories on two boxes with the syntax: dest-host# rsync -av -e ssh --delete --progress source-host:/home/ /home/ That's working well. Now I want to exclude /home/httpd/* from the process. (I don't want web changes on one box to affect the other box.) Which of the following is the best/correct one to use? [snip] None of the above. --exclude=/httpd/ Patterns are relative to the src/dest paths. [snip] Thanks to both JW Schultz and Max B. who suggested the same solution and helpfully pointed out why my guesses were wrong. -Dan __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: (fwd from uke@jeremy.org) thanks and patch
On 21 Mar 2002, Dave Dykstra [EMAIL PROTECTED] wrote: I guess that makes sense; I can't think of another easy to do what you want to do. Pretty obscure case though. Obscure now, but I expect not forever. If you consider it desirable for rsync to be able to do this task (encrypted backups on untrusted servers) all by itself, all it needs in addition to the --date-only option is the ability to accept a user-specified filter for each file to be transferred. If I were to make a patch for that, I don't suppose you'd want it? I don't know, I think it would depend on the implementation. There might be a number of uses that people could put it to. The thing that I don't like about it is that for most uses I can think of (compression is another example) it won't be able to use the rsync rolling checksum algorithm, which is mostly what people think of when they think of rsync. It's true that a lot of people end up using rsync just for its ability to recurse down two directory structures and identify differences, however, so they might be happy with it. I would think the option would default to have the option. So, you could possibly say that rsync should run gpg on the remote machine to decrypt the old backup, transfer differences, and then encrypt the new backup. Of course this is not so secure if you really distrust the remote admin. I once thought that it would be good to have a way for rsync to call commands in various scripting languages or through the shell at crucial points. I'm not really sure the complication it causes is justified. Machine-parseable output might get many of the same benefits. -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: (fwd from uke@jeremy.org) thanks and patch
On Wed, Mar 20, 2002 at 03:19:37PM -0800, jeremy bornstein wrote: On Thu, Mar 21, 2002 at 10:07:14AM +1100, Martin Pool wrote: It sounds like you're using asymmetric encryption. So I suppose every time you encrypt the file, gpg will generate a new session key, so an identical cleartext file will generate a completely different cyphertext file every time. Yes, this is correct. You probably ought to use the --whole-file option of rsync then because the rolling checksums are only going to slow you down. n Wed, Mar 20, 2002 at 05:22:46PM -0800, Martin Pool wrote: On 20 Mar 2002, jeremy bornstein [EMAIL PROTECTED] wrote: Dave Dykstra wrote: Wouldn't encrypting the file with gpg change the timestamp as well as the size, so rsync would still copy the file? It certainly does--which is why I reset it afterwards. Although the backup script I use is pretty simple, having this patch to rsync does not obviate it. I actually call rsync twice--once to determine the list of files to be transferred, and once to transfer the encrypted files. In-between I do the actual encryption (and munging of the mod dates). Oh, do you mean you fiddle the mtimes of the source files to be the same as those of the destination files, and you want rsync to therefore not transfer them? Rather than going to all that trouble, why not just have your script produce an exclude file? Yes, and use --ignore-times to always transfer the files you select. - Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: (fwd from uke@jeremy.org) thanks and patch
On Thu, Mar 21, 2002 at 08:39:44AM -0600, Dave Dykstra wrote: You probably ought to use the --whole-file option of rsync then because the rolling checksums are only going to slow you down. Ah, thanks! Oh, do you mean you fiddle the mtimes of the source files to be the same as those of the destination files, and you want rsync to therefore not transfer them? Rather than going to all that trouble, why not just have your script produce an exclude file? No, that isn't it. (Btw I don't seem to have received the original mail from Martin, only Dave's quoted version of it.) After determining the list of files to transfer with the patched rsync, based on mod dates, I encrypt each modified file and set the encrypted file's mod date to match the mod date of the *local* file. Yes, and use --ignore-times to always transfer the files you select. This isn't necessary. Only files to be transferred are encrypted, and the encrypted files are placed in a directory all their own--a different directory than where the original source files are. Thus the second time I call rsync--when the actual transfers are performed--rsync only sees the files which have already been encrypted and which are intended for transfer. It's only necessary to ensure that rsync doesn't delete files absent in the source tree--which is fine with me since the dest tree is a backup, after all. It seems that I must be explaining this terribly--I apologize! -j -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: (fwd from uke@jeremy.org) thanks and patch
On Thu, Mar 21, 2002 at 11:24:07AM -0600, Dave Dykstra wrote: Oh, I see, you want to use your new --date-only option on the first pass when you're determining which files to transfer, before you encrypt them. Yes! I guess that makes sense; I can't think of another easy to do what you want to do. Pretty obscure case though. Obscure now, but I expect not forever. If you consider it desirable for rsync to be able to do this task (encrypted backups on untrusted servers) all by itself, all it needs in addition to the --date-only option is the ability to accept a user-specified filter for each file to be transferred. If I were to make a patch for that, I don't suppose you'd want it? It'd still need an encrypting filter, but that's essentially a one line sample that could be included in the docs. (For symmetric encryption anyway.) -j -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: (fwd from uke@jeremy.org) thanks and patch
On Thu, Mar 21, 2002 at 09:42:21AM -0800, jeremy bornstein wrote: On Thu, Mar 21, 2002 at 11:24:07AM -0600, Dave Dykstra wrote: Oh, I see, you want to use your new --date-only option on the first pass when you're determining which files to transfer, before you encrypt them. Yes! I guess that makes sense; I can't think of another easy to do what you want to do. Pretty obscure case though. Obscure now, but I expect not forever. If you consider it desirable for rsync to be able to do this task (encrypted backups on untrusted servers) all by itself, all it needs in addition to the --date-only option is the ability to accept a user-specified filter for each file to be transferred. If I were to make a patch for that, I don't suppose you'd want it? I don't know, I think it would depend on the implementation. There might be a number of uses that people could put it to. The thing that I don't like about it is that for most uses I can think of (compression is another example) it won't be able to use the rsync rolling checksum algorithm, which is mostly what people think of when they think of rsync. It's true that a lot of people end up using rsync just for its ability to recurse down two directory structures and identify differences, however, so they might be happy with it. I would think the option would default to --no-whole-file and imply your --date-only functionality even if we don't have the option. (If we did want --date-only functionality as a separate option I think it should be called --times-only to go along with --ignore-times). It'd still need an encrypting filter, but that's essentially a one line sample that could be included in the docs. (For symmetric encryption anyway.) - Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: (fwd from uke@jeremy.org) thanks and patch
Wouldn't encrypting the file with gpg change the timestamp as well as the
size, so rsync would still copy the file?
- Dave Dykstra
On Tue, Mar 19, 2002 at 08:21:36AM -0800, jeremy bornstein wrote:
Martin,
The encryption program I'm using, gpg, includes a small bit of header
information with the encrypted file, thus changing the size. Gpg is a
public key encryption program which at least includes the numeric key
ID of the recipient's key. Since folks can have many keys, this is
useful information to have with each bit of data. It might be
possible to strip this information off, but then the whole process
would be version-sensitive and thus error-prone, which is not what I'd
like in a backup program!
(There's much more info at URL:http://www.gnupg.org/ if you like.)
I suspect I'm not the only one who would be interested in using this
feature for this purpose, but of course I can't say for certain.
Best,
-jeremy
On Tue, Mar 19, 2002 at 06:11:44AM +1100, Martin Pool wrote:
Jeremy,
I'm glad you like rsync.
Why does your encryption program not produce a file of the same size
every time it is run on the same input? I can see what the patch
does, but I'm having a bit of trouble understanding whether it would
be generally useful.
--
Martin
Date: Sun, 17 Mar 2002 06:31:40 -0800
From: jeremy bornstein [EMAIL PROTECTED]
To: Martin Pool [EMAIL PROTECTED]
Subject: thanks and patch
Greetings, and thanks for all of your work on the wonderful rsync!
I recently had the need to transfer files only with different mod
dates (and to *not* transfer them based on file size differences).
This is because I'm backing up files remotely on an untrusted machine,
so I'm encrypting them with gpg before transfer. I discovered that
rsync didn't already have a --date-only flag, so I added one and am
enclosing the diffs in case you (as I hope) decide to include this
option in future releases.
Again, thanks!
Best Regards,
Jeremy Bornstein
diff rsync-2.5.4/README rsync-2.5.4-patched/README
70a71
--date-only only use modification date when determining if a
file should be transferred
Common subdirectories: rsync-2.5.4/doc and rsync-2.5.4-patched/doc
diff rsync-2.5.4/generator.c rsync-2.5.4-patched/generator.c
39a40
extern int date_only;
50a52,56
if (date_only) {
return (cmp_modtime(st-st_mtime,file-modtime) == 0);
}
Common subdirectories: rsync-2.5.4/lib and rsync-2.5.4-patched/lib
diff rsync-2.5.4/options.c rsync-2.5.4-patched/options.c
64a65
int date_only=0;
223a225
rprintf(F, --date-only only use modification date when
determining if a file should be transferred\n);
265c267
OPT_LOG_FORMAT, OPT_PASSWORD_FILE, OPT_SIZE_ONLY, OPT_ADDRESS,
---
OPT_LOG_FORMAT, OPT_PASSWORD_FILE, OPT_SIZE_ONLY, OPT_DATE_ONLY,
OPT_ADDRESS,
278a281
{date-only,0, POPT_ARG_NONE, date_only},
704a708,710
if (date_only)
args[ac++] = --date-only;
Common subdirectories: rsync-2.5.4/packaging and rsync-2.5.4-patched/packaging
Common subdirectories: rsync-2.5.4/popt and rsync-2.5.4-patched/popt
diff rsync-2.5.4/rsync.1 rsync-2.5.4-patched/rsync.1
289a290
--date-only only use modification date when determining if a
file should be transferred
363a365,371
.IP
.IP \fB--date-only\fP
Normally rsync will skip any files that are
already the same length and have the same time-stamp\. With the
--date-only option files will be skipped if they have the same timestamp,
regardless of size\. This may be useful when the remote files have passed
through a size-changing filter, e.g. for encryption\.
diff rsync-2.5.4/rsync.yo rsync-2.5.4-patched/rsync.yo
260a261
--date-only only use modification date when determining if a
file should be transferred
326a328,333
dit(bf(--date-only)) Normally rsync will skip any files that are
already the same length and have the same time-stamp. With the
--date-only option files will be skipped if they have the same
timestamp, regardless of size. This may be useful when the remote
files have passed through a size-changing filter, e.g. for encryption.
Common subdirectories: rsync-2.5.4/testhelp and rsync-2.5.4-patched/testhelp
Common subdirectories: rsync-2.5.4/testsuite and rsync-2.5.4-patched/testsuite
Common subdirectories: rsync-2.5.4/zlib and rsync-2.5.4-patched/zlib
--
jeremy bornstein [EMAIL PROTECTED]
-*-
to be free of all authority, of your own and that of another, is
to die to everything of yesterday, so that your mind is always
fresh, always young, innocent, full of vigour and passion.
[j. krishnamurti, _freedom from the known_
Re: (fwd from uke@jeremy.org) thanks and patch
Dave Dykstra wrote:
Wouldn't encrypting the file with gpg change the timestamp as well as the
size, so rsync would still copy the file?
It certainly does--which is why I reset it afterwards.
Although the backup script I use is pretty simple, having this patch
to rsync does not obviate it. I actually call rsync twice--once to
determine the list of files to be transferred, and once to transfer
the encrypted files. In-between I do the actual encryption (and
munging of the mod dates).
-j
On Tue, Mar 19, 2002 at 08:21:36AM -0800, jeremy bornstein wrote:
Martin,
The encryption program I'm using, gpg, includes a small bit of header
information with the encrypted file, thus changing the size. Gpg is a
public key encryption program which at least includes the numeric key
ID of the recipient's key. Since folks can have many keys, this is
useful information to have with each bit of data. It might be
possible to strip this information off, but then the whole process
would be version-sensitive and thus error-prone, which is not what I'd
like in a backup program!
(There's much more info at URL:http://www.gnupg.org/ if you like.)
I suspect I'm not the only one who would be interested in using this
feature for this purpose, but of course I can't say for certain.
Best,
-jeremy
On Tue, Mar 19, 2002 at 06:11:44AM +1100, Martin Pool wrote:
Jeremy,
I'm glad you like rsync.
Why does your encryption program not produce a file of the same size
every time it is run on the same input? I can see what the patch
does, but I'm having a bit of trouble understanding whether it would
be generally useful.
--
Martin
Date: Sun, 17 Mar 2002 06:31:40 -0800
From: jeremy bornstein [EMAIL PROTECTED]
To: Martin Pool [EMAIL PROTECTED]
Subject: thanks and patch
Greetings, and thanks for all of your work on the wonderful rsync!
I recently had the need to transfer files only with different mod
dates (and to *not* transfer them based on file size differences).
This is because I'm backing up files remotely on an untrusted machine,
so I'm encrypting them with gpg before transfer. I discovered that
rsync didn't already have a --date-only flag, so I added one and am
enclosing the diffs in case you (as I hope) decide to include this
option in future releases.
Again, thanks!
Best Regards,
Jeremy Bornstein
diff rsync-2.5.4/README rsync-2.5.4-patched/README
70a71
--date-only only use modification date when determining if a
file should be transferred
Common subdirectories: rsync-2.5.4/doc and rsync-2.5.4-patched/doc
diff rsync-2.5.4/generator.c rsync-2.5.4-patched/generator.c
39a40
extern int date_only;
50a52,56
if (date_only) {
return (cmp_modtime(st-st_mtime,file-modtime) == 0);
}
Common subdirectories: rsync-2.5.4/lib and rsync-2.5.4-patched/lib
diff rsync-2.5.4/options.c rsync-2.5.4-patched/options.c
64a65
int date_only=0;
223a225
rprintf(F, --date-only only use modification date when
determining if a file should be transferred\n);
265c267
OPT_LOG_FORMAT, OPT_PASSWORD_FILE, OPT_SIZE_ONLY, OPT_ADDRESS,
---
OPT_LOG_FORMAT, OPT_PASSWORD_FILE, OPT_SIZE_ONLY, OPT_DATE_ONLY,
OPT_ADDRESS,
278a281
{date-only,0, POPT_ARG_NONE, date_only},
704a708,710
if (date_only)
args[ac++] = --date-only;
Common subdirectories: rsync-2.5.4/packaging and rsync-2.5.4-patched/packaging
Common subdirectories: rsync-2.5.4/popt and rsync-2.5.4-patched/popt
diff rsync-2.5.4/rsync.1 rsync-2.5.4-patched/rsync.1
289a290
--date-only only use modification date when determining if a
file should be transferred
363a365,371
.IP
.IP \fB--date-only\fP
Normally rsync will skip any files that are
already the same length and have the same time-stamp\. With the
--date-only option files will be skipped if they have the same timestamp,
regardless of size\. This may be useful when the remote files have passed
through a size-changing filter, e.g. for encryption\.
diff rsync-2.5.4/rsync.yo rsync-2.5.4-patched/rsync.yo
260a261
--date-only only use modification date when determining if a
file should be transferred
326a328,333
dit(bf(--date-only)) Normally rsync will skip any files that are
already the same length and have the same time-stamp. With the
--date-only option files will be skipped if they have the same
timestamp, regardless of size. This may be useful when the remote
files have passed through a size-changing filter, e.g. for encryption.
Common subdirectories: rsync-2.5.4/testhelp and rsync-2.5.4-patched/testhelp
Common subdirectories: rsync-2.5.4/testsuite and rsync-2.5.4-patched
Re: (fwd from uke@jeremy.org) thanks and patch
On Tue, Mar 19, 2002 at 08:21:36AM -0800, jeremy bornstein wrote: The encryption program I'm using, gpg, includes a small bit of header information with the encrypted file, thus changing the size. Gpg is a public key encryption program which at least includes the numeric key ID of the recipient's key. Since folks can have many keys, this is useful information to have with each bit of data. It might be possible to strip this information off, but then the whole process would be version-sensitive and thus error-prone, which is not what I'd like in a backup program! It sounds like you're using asymmetric encryption. So I suppose every time you encrypt the file, gpg will generate a new session key, so an identical cleartext file will generate a completely different cyphertext file every time. On 20 Mar 2002, jeremy bornstein [EMAIL PROTECTED] wrote: Wouldn't encrypting the file with gpg change the timestamp as well as the size, so rsync would still copy the file? It certainly does--which is why I reset it afterwards. Why not just re-encrypt the file only if it has changed since the last transfer? You could do that either by keeping the encrypted file on the origin machine, or by using rsync to look at the modification time on the remote machine. (I'm not just saying this to be difficult. We can't merge patches unless there's some reason to believe people would actually use them, or otherwise the code will become a complete mess.) -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: (fwd from uke@jeremy.org) thanks and patch
On Thu, Mar 21, 2002 at 10:07:14AM +1100, Martin Pool wrote: It sounds like you're using asymmetric encryption. So I suppose every time you encrypt the file, gpg will generate a new session key, so an identical cleartext file will generate a completely different cyphertext file every time. Yes, this is correct. On 20 Mar 2002, jeremy bornstein [EMAIL PROTECTED] wrote: Wouldn't encrypting the file with gpg change the timestamp as well as the size, so rsync would still copy the file? It certainly does--which is why I reset it afterwards. Why not just re-encrypt the file only if it has changed since the last transfer? You could do that either by keeping the encrypted file on the origin machine, or by using rsync to look at the modification time on the remote machine. Yes, this is what I do: use rsync to look at the mod time on the remote machine as compared to the mod time of the original (unencrypted) file on the local machine. I can't keep the encrypted files because of disk space limits. Files are encrypted only if rsync tells me that the local file has changed. (This is what the patch is for.) (I'm not just saying this to be difficult. We can't merge patches unless there's some reason to believe people would actually use them, or otherwise the code will become a complete mess.) Of course not--I completely understand. I suspect that my use is not unique, but I don't have any supporting specifics and I won't discount the possibility that it's not worth supporting in your software. -j -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: (fwd from uke@jeremy.org) thanks and patch
On 20 Mar 2002, jeremy bornstein [EMAIL PROTECTED] wrote: Dave Dykstra wrote: Wouldn't encrypting the file with gpg change the timestamp as well as the size, so rsync would still copy the file? It certainly does--which is why I reset it afterwards. Although the backup script I use is pretty simple, having this patch to rsync does not obviate it. I actually call rsync twice--once to determine the list of files to be transferred, and once to transfer the encrypted files. In-between I do the actual encryption (and munging of the mod dates). Oh, do you mean you fiddle the mtimes of the source files to be the same as those of the destination files, and you want rsync to therefore not transfer them? Rather than going to all that trouble, why not just have your script produce an exclude file? Perhaps you could also put a link to your script into the faq somewhere. I'm sure other people would be interested in making gpg-encrypted backups. -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: (fwd from uke@jeremy.org) thanks and patch
Wouldn't using detached signatures make more sense for this application? -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
