similar to: Patching for --omit-symlink-times?

https://bugzilla.samba.org/show_bug.cgi?id=7668 Summary: Add --omit-symlink-times option, same purpose as --omit- dir-times Product: rsync Version: 3.0.7 Platform: All OS/Version: FreeBSD Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned at

https://bugzilla.samba.org/show_bug.cgi?id=12742 Bug ID: 12742 Summary: a proposal: fix bogus nanosecond mtimes on transfer (patch included) Product: rsync Version: 3.1.1 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 Component: core

Hi Everyone, The following feature request was received by a Debian user; could you comment on it? I think this seems reasonable, but perhaps should be enabled only conditionally (as if the argument parser isn't stressed enough). Thanks, Justin On Fri, Jul 23, 2004 at 05:09:09PM -0300, Pedro Zorzenon Neto wrote: > Package: rsync > Version: 2.6.2-2 > Severity: wishlist > Tags:

Dear All, Along with the files that suddenly disappear, we have a bit of a problem with these that do not. Namely, in my test runs I can see a small but stable set of files, that rsync is repeatedly trying to transfer, and then repeatedly fails to updates their times ; and then the story repeats itself. The situation is illustrated by the log snippet below, where I have changed file names to

The included patch for openssh 3.0.2p1 implements overlapping read requests for the sftp client. It should be able to handle weird cases such as shriking files and reordered responses. This is only the first shot, and I'd be happy for any comments. I plan to implement something similar for the write path if this works out well. The maximum number of outstanding requests is quite high at

https://bugzilla.samba.org/show_bug.cgi?id=7621 Summary: Special handling of lutimes ENOSYS failures does not work as intended Product: rsync Version: 3.1.0 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org

Similar to --omit-{dir,link}-times: --omit-device-times omit device files from --times --omit-special-times omit sockets and fifos from --times Also, fix corner case that allows --omit-dir-times to be ignored. See unchanged_attrs() and recv_generator()'s call to try_dests_non(). Marc. diff -aNpRruz -X /etc/diff.excludes rsync-3.2.7/generator.c devel-3.2.7/generator.c ---

I haven't been able to find what is responsible for altering the time on APPENDed mail, but was able to come up with a temporary workaround ... simply calling utime() later on in the process resolves it. Below is my patch. Steve --- dovecot-1.0.beta7-orig/src/lib-storage/index/maildir/maildir-save.c 2006-03-25 05:53:43.000000000 -0500 +++

Is the following passage from help("file.info"): "Junction points and symbolic links are followed, so information is given about the file/directory to which the link points rather than about the link." correct? Could it be that Windows was not considered? help("file.symlink") mentions several Windows-related issues, but none of those are related to the following.

Hello, I'm using rsync as part of a centralised config management for several servers. I'm trying to monitor the mtime of a particular directory and confirm that the remote copies are approximately as new as the the local master. However, mtime on that directory is not being synced. Here's my rsync command: cd $confdir && rsync -avpzR --checksum -I -e "ssh"

Greetings rsync gurus, As I understand the documentation "--backup" without specifying "--backup-dir" implicitly sets "--omit-dir-times". It is then possible to negate the implied option by specifying it prefixed with "--no". The resulting option "--no-omit-dir-times" runs without any warnings or errors but does not transfer modification times on

https://bugzilla.samba.org/show_bug.cgi?id=13735 --- Comment #3 from Sébastien Béhuret <sbehuret at gmail.com> --- Thank you for suggesting the patches repo. An improved checksum/maybe-checksum algorithm would be great but there appears to be a lot of work to achieve this. Checksums are very handy for special cases (e.g. to detect and fix data corruption) but are still relatively slow and

Hello ML, Hello Stephan, > Hmm. Probably, the timezone configuration (i.e. the contents of TZ > timezone environment variable) somehow doesn't reach the final stages > of e-mail delivery. Well. I tried several ways of telling the lda or whatever is setting up the INTERNALDATE to use the CEST +0200. Although it is already setup on the server via a symlink from /etc/localtime to

https://bugzilla.samba.org/show_bug.cgi?id=13735 Bug ID: 13735 Summary: Synchronize files when the sending side has newer change times while modification times and sizes are identical on both sides Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW

Details of the changes in second patch set as outlined in the first mail of this series: -------------------------------------------------------------------------------------------------------------------------- diff --git a/usr/include/arch/aarch64/klibc/archconfig.h b/usr/include/arch/aarch64/klibc/archconfig.h index 5cc1e7e..5ee278d 100644 --- a/usr/include/arch/aarch64/klibc/archconfig.h +++

It looks like I need to elaborate further to get a feedback. I checked the rsync source code and it is using utime() to restore atime file attribute. It is fine to change ctime for that transferred file in this case. What we are having problem is that when rsync gets kicked off and transfers one file to the destination, this action changes ctime of "all" files in the same

Hello, I'm having problems with rsync 3.0.5 setting the mtime. I haven't see anything in the newer changelogs about it though... I am running rsync over SSH *from* a jail on one machine *to* a different host machine, and pulling files from that host into the jail. The problem is that the mtime never gets updated, so on every run it transfers the same files. There aren't any

Hello, This is probably a long email, but please bear with me. I plan to submit a patch and would like to explain what I will do before doing it so I don't lose time if there's some flaw in my plan. I currently use sshfs to mount directories from some computers and a NAS into other computers. I recently noticed that when copying some files from one computer into one of these sshfs

I've put some thought into adding DB support to rsync (in a future release). This would allow it to maintain some extra information about files and be able to lookup information rapidly. This would support things like caching of checksum information, finding files to hard-link with, saving file attributes separately from the files (allowing non-root preservation of full file attributes as

I've done a bit more investigation into this issue. Here is my current understanding of the situation: 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all platforms except for Linux. 2. My package defines a C function, "xrealloc", for internal use. 3. The libreadline library that R links to defines a different version of "xrealloc". 4. On Linux, when I