Displaying 20 results from an estimated 500 matches similar to: "crtimes discrepancy on PPC"
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:
2008 Sep 27
1
Bug with crtimes and hard links?
I've been getting spurious unnecessary copying of files on OSX when
using the crtimes patch and the --crtimes -H options (version 3.0.4).
I can reliably demonstrate it (on OSX 10.5) by doing this several
times (as root):
rsync -v -N -axHAX --delete-during --fileflags --force-change /usr/
bin/ /tmp/foo/
I think I've tracked it down to the hard-link processing code in
2010 Feb 11
0
DO NOT REPLY [Bug 6276] crtimes.patch does not preserve creation dates on Mac x86_64 only
Wayne,
I tried changing "unsigned long" to "uint32" as you suggested, but
that doesn't work.
The compiler adds padding to the struct to make the fields 64-bit
aligned and it has the same problem. ?To convince the compiler
that the timespec really should come immediately after the length, the
struct can be packed with the pragma pack directive. ?I tested the
following, and
2010 Sep 16
4
DO NOT REPLY [Bug 7685] New: rsync should not set the creation data on the root folder of an HFS+ volume
https://bugzilla.samba.org/show_bug.cgi?id=7685
Summary: rsync should not set the creation data on the root
folder of an HFS+ volume
Product: rsync
Version: 3.0.7
Platform: x86
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P3
Component: core
AssignedTo: wayned at
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
2006 Nov 12
1
Superfluous error msgs: "failed to set times ..."
When rsync'ing to an Ext2 file system (via SSH), then I frequently get
error messages such as "failed to set times ...". AFAICS, these error
messages are caused by rsync trying to change the time (and permissions,
ownership) of symbolic links, which according to my knowledge is not
possible on Ext2.
Is there any way to get rid of these supposedly superfluous error
messages?
rsync
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) ==
2009 Apr 18
8
DO NOT REPLY [Bug 6276] New: crtimes.patch does not preserve creation dates on Mac x86_64 only
https://bugzilla.samba.org/show_bug.cgi?id=6276
Summary: crtimes.patch does not preserve creation dates on Mac
x86_64 only
Product: rsync
Version: 3.0.6
Platform: x86
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P3
Component: core
AssignedTo: wayned@samba.org
2008 Feb 21
1
universal binary and crtimes
Hi All,
I promise I won't bug you anymore about this but I did find that
the compiled universal binary on rsync3.0.pre10 does preserve creation
dates across platforms with the old osx-create-time.diff patch but not
with the crtimes patch. If anyone has a clue about this I would be
happy to fix it. Thanks again Rob D
PS so close!
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
+ ?
2010 Apr 02
6
L2ARC & Workingset Size
Hi all
I ran a workload that reads & writes within 10 files each file is 256M, ie,
(10 * 256M = 2.5GB total Dataset Size).
I have set the ARC max size to 1 GB on etc/system file
In the worse case, let us assume that the whole dataset is hot, meaning my
workingset size= 2.5GB
My SSD flash size = 8GB and being used for L2ARC
No slog is used in the pool
My File system record size = 8K ,
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
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?
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
2015 Sep 14
3
[Bug 11521] New: rsync does not use high-resolution timestamps to determine file differences
https://bugzilla.samba.org/show_bug.cgi?id=11521
Bug ID: 11521
Summary: rsync does not use high-resolution timestamps to
determine file differences
Product: rsync
Version: 3.1.2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: core
2012 Aug 01
17
[PATCH] add crtime to the snapshot list
From: Anand <anand.jain@oracle.com>
This patch adds creation-time to the snapshot list display,
which would help user to better manage the snapshots when
number of snapshots grow substantially. This patch is developed
and on top of the send/receive btrfs and btrfs-progs repo at
git://github.com/ablock84/linux-btrfs.git (send-v2)
git://github.com/ablock84/btrfs-progs.git (send-v2)
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
2012 Aug 20
3
[Bug 9103] New: ext4 creation timestamp
https://bugzilla.samba.org/show_bug.cgi?id=9103
Summary: ext4 creation timestamp
Product: rsync
Version: 3.1.0
Platform: x64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P5
Component: core
AssignedTo: wayned at samba.org
ReportedBy: enda_k2 at yahoo.com
QAContact:
2018 Mar 16
1
Discrepancy: R sum() VS C or Fortran sum
My simple functions were to compare the result with the gfortran
compiler sum() function. I thought that the Fortran sum could not be
less precise than R. I was wrong. I am impressed. The R sum does in fact
match the result if we use the Kahan algorithm.
P.
I am glad to see that R sum() is more accurate than the gfortran
compiler sum.
On 16/03/18 11:37 AM, luke-tierney at uiowa.edu wrote:
2018 Mar 16
3
Discrepancy: R sum() VS C or Fortran sum
Hi all,
I found a discrepancy between the sum() in R and either a sum done in C
or Fortran for vector of just 5 elements. The difference is very small,
but this is a very small part of a much larger numerical problem in
which first and second derivatives are computed numerically. This is
part of a numerical method course I am teaching in which I want to
compare speeds of R versus Fortran (We