similar to: [Bug 12742] New: a proposal: fix bogus nanosecond mtimes on transfer (patch included)

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 existing APIs guestfs_stat, guestfs_lstat and guestfs_lstatlist return a stat structure that contains atime, mtime and ctime fields that store only the timestamp in seconds. Modern filesystems can store timestamps down to nanosecond granularity, and the ordinary glibc stat(2) wrapper will return these in "hidden" stat fields: struct timespec st_atim; /* Time of last

On Monday 22 September 2014 13:48:38 Richard W.M. Jones wrote: > The existing APIs guestfs_stat, guestfs_lstat and guestfs_lstatlist > return a stat structure that contains atime, mtime and ctime fields > that store only the timestamp in seconds. > > Modern filesystems can store timestamps down to nanosecond > granularity, and the ordinary glibc stat(2) wrapper will return these

schilytools star has the ability to restore ctimes from tarfiles. This is useful when restoring filesystems as root in single user mode, and I thought I'd like rsync to do the same. I started working off the rsync-patches/atimes.diff patch but noticed that this patch is buggy and presently does not work. (It fails to set the atime and it fails to set the mtime too). Even if this is fixed

https://bugzilla.samba.org/show_bug.cgi?id=13385 Bug ID: 13385 Summary: rsync sometimes silently transfers more or fewer mtimes than it should Product: rsync Version: 3.1.3 Hardware: All OS: Linux Status: NEW Severity: regression Priority: P5 Component: core

Hi all, I'd like to output structured data for all of the gathered timers with the full nanosecond numbers to a file, say JSON for example. Does the timer infrastructure support this, or at least installing some custom print handlers? If not, does any of that sound like an interesting patch? David

I noticed that rsync is happy to hard-link a device node from a --link-dest dir even if its mtime differs from that of the source device node and --times is given. Is this behavior expected? It seems to break the rule that a difference in preserved attributes disqualifies a hard link. To see the behavior, run the following as root: mkdir src dest basis mknod src/null c 1 3 sleep 1 mknod

Hello again, as stated earlier there is a problem with mtime setting on directories during healing in replication setup. Today I tested 2.0.5 and found out that the handling is more or less generally buggy for directory mtimes. Simply try this: untar some kernel archive on your local disk and look at the mtime of the created top directory. now untar the same archive on an exported gluster fs and

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 +++

Hi, I'm running the following command as a local copy command. faheem at bulldog:/mnt/data$ sudo rsync -abvz --super /data/ . Origin directory faheem at bulldog:/data$ ls -la total 28 drwxr-xr-x 7 root root 4096 Jun 26 08:34 . drwxr-xr-x 25 root root 4096 Apr 13 17:09 .. drwxr-xr-x 2 owzar001 root 4096 Nov 6 2010 CTS drwxr-xr-x 2 owzar001 owzar001 4096 Aug 27 2010

On Thu, Dec 25, 2014 at 2:48 AM, Ingo Brückl <ib at wupperonline.de> wrote: > On systems using nanoseconds differences should be taken into > consideration. > The problem is that if you transfer from a filesystem that has nanoseconds to one that does not support it, rsync would consider most of the files to be constantly different, since the nanosecond values would only match if

Commit-ID: bae97a14a3dab910cd57c1d36003b18a869f788f Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=bae97a14a3dab910cd57c1d36003b18a869f788f Author: Martijn Dekker <martijn at inlv.org> AuthorDate: Wed, 7 Mar 2018 17:32:29 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] builtin: Greater resolution

Commit-ID: e86e3a7edc8934dc6a9ecd4bb360d19672f65ccf Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=e86e3a7edc8934dc6a9ecd4bb360d19672f65ccf Author: Martijn Dekker <martijn at inlv.org> AuthorDate: Wed, 7 Mar 2018 17:32:29 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:54 +0000 [klibc] dash: builtin: Greater

https://bugzilla.samba.org/show_bug.cgi?id=5867 Summary: rsync with ACLs resets mtime on targets Product: rsync Version: 3.0.4 Platform: x86 OS/Version: FreeBSD Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: samba@byshenk.net

having trouble compiling dovecot-1.1hg latest pull I'm amost thinking _GNU_SOURCE needs to be defined as its built to work Any suggestions welcome. make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/dan/software_projects/dovecot-1.1/src/lib-storage/list' Making all in index make[4]: Entering directory

Dear collegaues, please evaluate the patch attached, which allow to use both --detect-renamed and --fileflags extra features. This is meta-patch which sould be applied to detect-renamed. fileflags patch should be applied first, following by the modified detect-renamed patch. It is included in current FreeBSD port, but it seems it would be much more useful to be supported by samba

This patch adds all the missing commonly used UNIX attributes: st_dev, st_ino, st_nlink, st_rdev, st_blocks, st_blksize, st_ctime. In addition it extends st_atime and st_mtime to 64bits, and adds nanosecond resolution to all three timestamps. This is implemented as an extension to the ATTR message. This patch alone is sufficient for SSHFS to be able to use these attributes. The following two

Can anyone comment on the easiest way to get the PPS Kit kernel patch to work on a CentOS-5 system? I'd rather not use a plain vanilla kernel. http://www.kernel.org/pub/linux/daemons/ntp/PPS/

On Aug 10, 2018, at 1:28 PM, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > * The clock stuff being added in C++20 has already been discussed here. I’ve missed the discussions on file_time_type, however I thought I should throw in my opinion here before it is too late to do anything about it. I believe it is a mistake to model file_time_type with 128 bits. It

try /sbin/depscan.sh --update