Displaying 20 results from an estimated 1000 matches similar to: "Superfluous error msgs: "failed to set times ...""
2008 Mar 04
1
preserve ctimes of *unchanged* directories on receiver
'rsync -a' updates the ctime on a directory even if no file in that directory
has changed. A kind of workaround is to use '-O', but then the mtimes of
directories are not preserved.
(Usage example where this is important: maintain a copy of filesystem A in
filesystem B, and use filesystem B as the source for incremental backups
(e.g., with star). rsync is run before an
2008 Sep 29
1
crtimes discrepancy on PPC
On a PPC machine running Mac OS X, I noticed that creation time is not
preserved for files that are transferred (i.e. versus files that are
not transferred, or files that have only attribute changes). I
discovered two things that work together to cause this:
1) cmp_time (util.c) doesn't check for negative values provided in
file1 or file2. If file2 is positive, and file1 is
2004 May 06
2
rsync-2.6.2: NFS clients confused after an rsync
We use rsync to update an nfs server. After an update, we noticed that
a large number of clients didn't see the updated data.
It took me a while to be able to reliably reproduce this problem, but it
happens on old and new versions of rysnc. It also happens across all
the platforms we use here (sun/linux/netapp).
This shows the problem: [Note my home directory is NFS mounted]
2016 Jan 20
2
[PATCH] Consider nanoseconds when quick-checking for unchanged files
I wrote on Fri, 02 Jan 2015 16:02:27 +0100:
> --- a/generator.c 2014-06-14 01:05:08.000000000 +0200
> +++ b/generator.c 2015-01-02 15:50:30.000000000 +0100
> @@ -588,7 +588,14 @@
> if (ignore_times)
> return 0;
> - return cmp_time(st->st_mtime, file->modtime) == 0;
> + return cmp_time(st->st_mtime, file->modtime) ==
2004 May 10
2
read error produces null-byte-filled destination file
I've run into a bug in the IO handling when reading a file. Suppose I
have a file that lives on an NFS filesystem. That filesystem is NOT
being exported with auth=0 permissions. So, if I try to access a file
as root, it successfully opens the file, but subsequent reads fail with
EACCES. This produces a destination file full of null bytes. I
noticed this with 2.5.7, but checked 2.6.2 as
2014 Dec 25
8
[PATCH] Consider nanoseconds when quick-checking for unchanged files
On systems using nanoseconds differences should be taken into consideration.
--- a/generator.c 2014-06-14 01:05:08.000000000 +0200
+++ b/generator.c 2014-12-25 11:19:54.000000000 +0100
@@ -588,7 +588,13 @@
if (ignore_times)
return 0;
- return cmp_time(st->st_mtime, file->modtime) == 0;
+ return cmp_time(st->st_mtime, file->modtime) == 0
+#ifdef ST_MTIME_NSEC
+ ?
2008 Feb 15
4
Revised flags patch
Hi,
first of all, sorry for taking so long. Unfortunately, some other tasks
kept coming up. Anyway, attached is the version of the flags patch, that
is based on the one I'm using with 2.6.9. It is against the rsync-3.0.0pre9
release.
I've included the option name change from the repository, so the
option is now called --fileflags. Improved from the previously
distributed version is the
2004 Apr 20
1
improved atime patch
I posted a patch a few days ago that adds copying of atime. At that
time, it was just enabled with -t/--times. After some time, we have
figured out that that choice might not have been the best. Here's a
new version of the patch (relative to CVS) that adds -A/--copy-atime
instead. It also includes a test case.
Any feedback on this patch and/or the previous one that I posted?
2004 Apr 10
0
patches for copying atimes
Hi.
Here's a patch for copying the atimes of files when -t/--times is
given. I bumped the protocol to 29 since it sends more data over the
wire. It obviously does not send the atime if it's sending data to an
older rsync version.
It passes all the tests (including the added atime.test) for me on a:
Linux Debian/3.0 gcc 2.95.4 (debian), glibc 2.2.5 system.
Any questions/feedback? I
2012 Feb 18
4
FADV_DONTNEED support
While going through an old todo list I found that these patches had fallen by
the way-side. About a year ago I initiated a discussion[1] with the Linux
kernel folks regarding the lack of any useable fadvise support on the kernel
side. As a result, I was observing extremely poor performance on my server
after backup as executable pages were being swapped out in favor of data
waiting to be flushed
2009 Aug 29
3
DO NOT REPLY [Bug 6672] New: mtim.tv_nsec not used when reading time of a file
https://bugzilla.samba.org/show_bug.cgi?id=6672
Summary: mtim.tv_nsec not used when reading time of a file
Product: rsync
Version: 3.0.6
Platform: Other
OS/Version: All
Status: NEW
Severity: major
Priority: P3
Component: core
AssignedTo: wayned at samba.org
ReportedBy: antonio at
2004 Feb 17
1
[patch] Make robust_rename() handle EXDEV.
All callers of robust_rename() call copy_file() if EXDEV is received. This
patch moves the copy_file() call into robust_rename().
Patch Summary:
-12 +1 backup.c
-15 +2 rsync.c
-9 +33 util.c
-------------- next part --------------
patchwork diff util.c
--- util.c 2004-02-17 09:58:44.000000000 -0500
+++ util.c 2004-02-17 10:21:22.000000000 -0500
@@ -355,16 +355,40 @@
2003 Oct 03
2
Cygwin/rsync Hang Problem Testing Results
People of cygwin & rsync,
I recently attempted to get cygwin and rsync working to solve a
backup/mirroring need in my computer life. Well, as you might guess, I
ran into a little but of trouble.
Strangely enough, rsync seemed to be regularly hanging when I attempted
to do a "get" (sycronize a remote to a local dir). Well, considering I
want to automate this, that was not going
2002 Sep 10
0
[PATCH] Add --preserve-atime switch to rsync
In the past there have been discussions about adding a switch to rsync to
preserve the atime on files being copied by rsync. I needed this function
for a project I'm working on and decided to invent it. I've attached the
diffs. Note that this has the limitations describe in previous emails,
namely that preserving atime causes ctime to not be preserved.
*** Patch follows ***
***
2017 Apr 09
0
failed to set times on ... Invalid argument (22) and what to do with it
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
2014 May 31
1
[Bug 10643] New: cmp_time() returns incorrect result due to integer overflow
https://bugzilla.samba.org/show_bug.cgi?id=10643
Summary: cmp_time() returns incorrect result due to integer
overflow
Product: rsync
Version: 3.1.1
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: core
AssignedTo: wayned at samba.org
2018 Jul 11
5
[Bug 13522] New: Patch fileflags.diff and crtimes.diff
https://bugzilla.samba.org/show_bug.cgi?id=13522
Bug ID: 13522
Summary: Patch fileflags.diff and crtimes.diff
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: core
Assignee: wayned at samba.org
Reporter:
2006 Jan 24
1
propagate atimes with rsync-2.6.6 (fwd)
Dear Martin Pool.
We regularly use rsync for making backups of our file systems but we have
noticed that the atimes are not transferred with the files and are also
always updated on the sender's side. Therefore, we have created a modified
version of rsync based on rsync-2.6.6 protocol version 29 which transfers
the access times with the transferred files and also allows to preserve
the access
2011 Feb 05
2
rsync not reporting diskfull error
I am involved with the development of lbackup. This message to the rsync mailing list is related to the following thread on the lbackup-disccussion mailing list : http://tinyurl.com/lbackup-discussion-diskfull
Essentially, I am curious to if any one using rsync 3.0.7 on Mac OS (10.6) Server has experienced an out of disk space error and not had a message similar to the following reported :
>
2008 Mar 04
1
Several changes missing from [HEAD] fileflags.diff
Looking at http://rsync.samba.org/ftp/rsync/patches/fileflags.diff --
It looks like the changes from fileflags-fixes.diff patch were applied
to the patch from http://rsync.samba.org/ftp/rsync/rsync-patches-3.0.0.tar.gz
, but this entire chunk of the that original diff file was lost:
> diff -up a/config.h.in b/config.h.in
> --- a/config.h.in
> +++ b/config.h.in
> @@ -64,6 +64,9 @@