, that -c really hurts. If one wanted to live dangerously---with
the assumption that two files that otherwise match in all metadata
(including obviously length :) but whose timestamps differ in that one
has integer seconds and the other has the same integer seconds but
also nanoseconds, can rsync rea
ch, even though
both ends supported it.
Anyone who's used dirvish, or presumably similar tools such as
rsnapshot, from and to ext4 or other ns-supporting filesystems, will
be bitten by the problem of non-ns vs ns timestamps bloating backups
and breaking hardlinks, either when they manually use
https://bugzilla.samba.org/show_bug.cgi?id=11521
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=11521
--- Comment #2 from Andrey Gursky ---
(In reply to Michael McCracken from comment #1)
I believe the rsync maintainer might have commented this with at least the
reference to the mailing list [1], where this has been already proposed, though
ignore
https://bugzilla.samba.org/show_bug.cgi?id=11521
--- Comment #1 from Michael McCracken ---
Created attachment 11440
--> https://bugzilla.samba.org/attachment.cgi?id=11440&action=edit
patch to check hi-res timestamp in unchanged_file
--
You are receiving this mail because:
You are the QA Conta
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
Hi
On Wed, 29 Apr 2015 14:23:56 +0200 Frantisek Hanzlik wrote:
> Now I still do not understand why does not work this switch form:
> --chmod=D=775,F=664
This is not the proper syntax: suppress the = signs before the modes:
--chmod=D775,F664
--
Francis
--
Please use reply-all for most replies
ible (with rsync) re-create files timestamps? I mean
>> something like choosing a "-T" in the program mirror- from it's man
>> page e.g. there:
>> http://sunsite.univie.ac.at/textbooks/mirror/mirror.html#Flags
>>
>> "Do not do any file transfers just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --archive --itemize-changes --size-only --dry-run
Obviously the last one is so you can confirm what it is going to do.
On 04/26/2015 06:08 PM, Frantisek Hanzlik wrote:
> Please, is possible (with rsync) re-create files timestamps? I m
Please, is possible (with rsync) re-create files timestamps?
I mean something like choosing a "-T" in the program mirror- from
it's man page e.g. there:
http://sunsite.univie.ac.at/textbooks/mirror/mirror.html#Flags
"Do not do any file transfers just force the time-stamps of a
https://bugzilla.samba.org/show_bug.cgi?id=8198
--- Comment #5 from Matt McCutchen 2011-06-04 18:04:35
UTC ---
(In reply to comment #4)
> I do think that if the chroot call doesn't find a new timezone setup, that it
> should leave things alone. That is how things have always worked before, and
https://bugzilla.samba.org/show_bug.cgi?id=8198
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.samba.org/show_bug.cgi?id=8198
--- Comment #3 from Matt McCutchen 2011-06-04 03:36:12
UTC ---
E.g., the application could call a function freeze_config(int items) to preload
the configuration items it will need as indicated by the "items" bitmask and
then suppress future loading
https://bugzilla.samba.org/show_bug.cgi?id=8198
--- Comment #2 from Matt McCutchen 2011-06-04 03:25:27
UTC ---
The solution is a little messy and fails in the rare event that an rsync run
straddles a DST change.
Fundamentally, glibc is assuming that the new root directory is that of a
POSIX-lik
01.06.2011 14:06, samba-b...@samba.org пишет:
> https://bugzilla.samba.org/show_bug.cgi?id=8198
>
>Summary: rsync does not set TZ variable after chroot(), which
> confuses logging timestamps
>Product: rsync
>
https://bugzilla.samba.org/show_bug.cgi?id=8198
--- Comment #1 from Jan Kaluza 2011-06-01 10:07:01 UTC ---
Created attachment 6508
--> https://bugzilla.samba.org/attachment.cgi?id=6508
patch
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving thi
https://bugzilla.samba.org/show_bug.cgi?id=8198
Summary: rsync does not set TZ variable after chroot(), which
confuses logging timestamps
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Backup options are concered with files from what I can see after some
tests. Extra directory (--backup-dir) is an addition to keep things more
tidy. I guess the idea was to have some sort of protection against
careless rsync invocation, etc. - not as a solution for incremental
backups. I don't
p/desti/foo/bar
I'm using version 3.0.6. I've played around with various options but did
not find a combination where this worked. I scanned through the source,
and it appears as though rsync only creates directories as required by
files when they are moved over and doesn't update
Matt McCutchen wrote:
> On Sun, 2009-03-01 at 17:21 -0800, Bill Landry wrote:
>> I just setup my first rsyncd server and all is working well as far as
>> file syncing goes. However, I am a bit baffled by the fact that some of
>> the log entries in the rsyncd.log file are entered in local time and
Eberhard Moenkeberg wrote:
> Hi,
>
> On Sun, 1 Mar 2009, Matt McCutchen wrote:
>> On Sun, 2009-03-01 at 17:21 -0800, Bill Landry wrote:
>
>>> I just setup my first rsyncd server and all is working well as far as
>>> file syncing goes. However, I am a bit baffled by the fact that some of
>>> the
Hi,
On Sun, 1 Mar 2009, Matt McCutchen wrote:
> On Sun, 2009-03-01 at 17:21 -0800, Bill Landry wrote:
> > I just setup my first rsyncd server and all is working well as far as
> > file syncing goes. However, I am a bit baffled by the fact that some of
> > the log entries in the rsyncd.log file a
On Sun, 2009-03-01 at 17:21 -0800, Bill Landry wrote:
> I just setup my first rsyncd server and all is working well as far as
> file syncing goes. However, I am a bit baffled by the fact that some of
> the log entries in the rsyncd.log file are entered in local time and
> other are entered in GMT.
[22691] building file list
2009/03/01 23:21:06 [22691] unknown xxx.xxx.xxx.xxx some-module ()
some-file.txt
2009/03/01 23:21:06 [22691] sent 6299 bytes received 54 bytes total
size 37421
==
Note the different (but correct local time) timestamps for "connect" and
the others
On Thu, Apr 19, 2007 at 07:26:40PM -0700, Carson Gaspar wrote:
> Emit a WARNING and set to MAX_TIME_T on the destination? It's either
> that or an ERROR and fail the transfer.
I had considered forcing the time to MAX_TIME_T, but decided against
it because I didn't want all too-lar
Wayne Davison wrote:
Good point. I'm going to include the ability to transfer a > 4-byte
time_t value for protocol 30. We'll need to consider what should be
done if a value is too large for the destination system to handle.
Emit a WARNING and set to MAX_TIME_T on the destination? It's either
Wayne Davison wrote:
On Thu, Apr 19, 2007 at 05:20:59PM +0100, Jon Burgess wrote:
I use rsync as a backup tool (via rsnapshot) and noticed that it had a
problem with a couple of files which had timestamps way off in the
future.
That's a unix-time limitation. The current timestamp resol
On Thu, Apr 19, 2007 at 07:19:00PM +0100, Jon Burgess wrote:
> The particular problem I see where the timestamps 1940 != 2076 is due to
> a 64 bit time_t. On such platforms, increasing the modtime protocol
> entity from 4 to 8 bytes is sufficient to fix this.
Good point. I'm going
On Thu, 2007-04-19 at 10:30 -0700, Wayne Davison wrote:
> On Thu, Apr 19, 2007 at 05:20:59PM +0100, Jon Burgess wrote:
> > I use rsync as a backup tool (via rsnapshot) and noticed that it had a
> > problem with a couple of files which had timestamps way off in the
> > futur
On Thu, 2007-04-19 at 10:30 -0700, Wayne Davison wrote:
> On Thu, Apr 19, 2007 at 05:20:59PM +0100, Jon Burgess wrote:
> > I use rsync as a backup tool (via rsnapshot) and noticed that it had a
> > problem with a couple of files which had timestamps way off in the
> > futur
On Thu, Apr 19, 2007 at 05:20:59PM +0100, Jon Burgess wrote:
> I use rsync as a backup tool (via rsnapshot) and noticed that it had a
> problem with a couple of files which had timestamps way off in the
> future.
That's a unix-time limitation. The current timestamp resolution c
I use rsync as a backup tool (via rsnapshot) and noticed that it had a
problem with a couple of files which had timestamps way off in the
future. You can reproduce the problem quite simply:
$ touch -t 207608011200 foo
$ rsync -a foo bar
$ ls -l foo bar
-rw-rw-r-- 1 jburgess jburgess 0 Jun 26
https://bugzilla.samba.org/show_bug.cgi?id=3479
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|normal |enhancement
Status|NEW
https://bugzilla.samba.org/show_bug.cgi?id=3479
Summary: Request: timestamps in --log-format
Product: rsync
Version: 2.6.7
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
On Wed, Jul 13, 2005 at 05:01:55PM -0700, Steve Magee wrote:
> The problem is the timestamp are using localtime and Greenwich time.
This has come up:
http://lists.samba.org/archive/rsync/2005-January/011353.html
... several times before:
https://bugzilla.samba.org/show_bug.cgi?id=2607
Unfortun
on the older version of the kernel, both timestamps were using
localtime.
Jul 13 16:44:59 web rsyncd[26323]: rsync on app_web from
[EMAIL PROTECTED] (xxx.xxx.xxx.xxx)
Jul 13 23:45:11 web rsyncd[26323]: wrote 4335227 bytes read 295 bytes
total size 31683130932
Is there a way to get both tim
I actually have to use rsync-2.5.7-5.3E which is included in RHEL3.
I assume that the problem with the aging timestamps results in more
files are transferred...
I've no idea why the source timestamps are changed... Can anyone explain
this?? Or does anyone has an idea why it could h
I actually have to use rsync-2.5.7-5.3E which is included in RHEL3.
I assume that the problem with the aging timestamps results in more
files are transferred...
I've no idea why the source timestamps are changed... Can anyone explain
this?? Or does anyone has an idea why it could h
On Wed, May 25, 2005 at 09:24:50PM +1000, Juergen Busam wrote:
> how is it possible that the files age a few hours on the source?
If you're running at least 2.6.4, use the -i option to see a summary of
what differences rsync sees between the pairs of files. For instance, a
summary like this:
>f.
On Wed 25 May 2005, Juergen Busam wrote:
>
> I'm syncing a windows share from a NetApp filer to a local partition on
> my RHEL3 box. I observe the following behavior:
>
> - rsync syncs more than neccessary, files that haven't changed since years
> - files that have been synced, aged for an hour o
Hi all!
I'm syncing a windows share from a NetApp filer to a local partition on
my RHEL3 box. I observe the following behavior:
- rsync syncs more than neccessary, files that haven't changed since years
- files that have been synced, aged for an hour or two on the netapp host
Environment:
cifs
Hello listers,
I do not seem to be able to find a combination of rsync switches that
updates destination directory only if the contents of the files
changes *and* preserves files' original timestamps.
What I've tried so far:
1. --checksum --size-only --ignore-times with or witho
On Sat, Mar 08, 2003 at 01:13:17PM -0500, Haisam K. Ido wrote:
> Is there a way to make rsync check the local file system for changes in the files
> prior to it performing a diff with the remote site?
There is no built-in capability to do this in rsync. However, you can
implement this yourself.
Haisam K. Ido wrote:
> Max Bowsher wrote:
>> Haisam K. Ido wrote:
>>
>>> bob parker wrote:
>>>
I think so. It compares the size and timestamp of your local file
with the remote one of the same name of course. If it all matches
nothing is done unless you force it.
>>>
>>> If it doe
Max Bowsher wrote:
Haisam K. Ido wrote:
bob parker wrote:
I think so. It compares the size and timestamp of your local file
with the remote one of the same name of course. If it all matches
nothing is done unless you force it.
If it does that then it is not doing what I'm asking about.
I need to
Haisam K. Ido wrote:
> bob parker wrote:
>> I think so. It compares the size and timestamp of your local file
>> with the remote one of the same name of course. If it all matches
>> nothing is done unless you force it.
>
> If it does that then it is not doing what I'm asking about.
>
> I need to
bob parker wrote:
On Sun, 9 Mar 2003 05:45, Haisam K. Ido wrote:
thanks Bob.
The timestamp relative to the local first prior to any remote diffing. Is
that what you meant?
I think so. It compares the size and timestamp of your local file with the
remote one of the same name of course. If it a
On Sun, 9 Mar 2003 05:45, Haisam K. Ido wrote:
> thanks Bob.
>
> The timestamp relative to the local first prior to any remote diffing. Is
> that what you meant?
>
I think so. It compares the size and timestamp of your local file with the
remote one of the same name of course. If it all matches
thanks Bob.
The timestamp relative to the local first prior to any remote diffing. Is that what
you meant?
bob parker wrote:
On Sun, 9 Mar 2003 05:13, Haisam K. Ido wrote:
Is there a way to make rsync check the local file system for changes in the
files prior to it performing a diff with the r
On Sun, 9 Mar 2003 05:13, Haisam K. Ido wrote:
> Is there a way to make rsync check the local file system for changes in the
> files prior to it performing a diff with the remote site?
My understanding is that it does nothing if your file(s) has the same
timestamp and size. Unless you use the -I
Is there a way to make rsync check the local file system for changes in the files
prior to it performing a diff with the remote site?
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
>Date: Wed, 16 Oct 2002 14:26:46 -0500
>To: Wayne Davison <[EMAIL PROTECTED]>
>From: Sean O'Neill <[EMAIL PROTECTED]>
>Subject: Re: HELP !!! Problem with file timestamps updating "weird" during
>rsync data pull
>Cc: [EMAIL PROTECTED]
>
>At 1
At 12:10 PM 10/16/2002 -0700, Wayne Davison wrote:
>On Wed, Oct 16, 2002 at 01:36:10PM -0500, Sean O'Neill wrote:
> > The timestamp should match that of the system the data is pulled from
> right
> > ? Well, it doesn't from time to time. The time stamp sometimes gets
> > updated as just "Oct 16
On Wed, Oct 16, 2002 at 01:36:10PM -0500, Sean O'Neill wrote:
> The timestamp should match that of the system the data is pulled from right
> ? Well, it doesn't from time to time. The time stamp sometimes gets
> updated as just "Oct 16 2002"
This is what most unix systems display for a future
Running rsync 2.3.1, 2.4.1, and 2.5.5 on Solaris 8 on various system.
I'm using rsync to pull data over for collecting performance data for
graphing in Orca. What I'm seeing is the timestamps from time to time of
the data files is being setup "weird" on the system the data
Hi all,
I'm having a little trouble using rsync from my windows machine to a Linux
server in a different time zone. I did some hunting through the
documentation and through the code, but it's not clear to me what rsync
does in this case.
I gather that in principle it uses UTC at both ends. Wil
2000
I think I will take a look at smbmount/samba to see if anything has
changed there. Its making my head hurt trying to figure out what is
going on.. the timestamps are always off by two seconds and always in
the same direction, so it is as if things are getting rounded down on
read and roun
onds off from the sending end.
>
> When I use 'ls -l --full-time' on the NT shares i see that all the
> timestamps on the receiving end have an even number in the seconds
> column. On the sending end I see a mixture of odd and event seconds
> (note most of the files on the
g
the following packages:
samba-2.0.7-36
samba-client-2.0.7-36
rsync-2.4.6-2
Since the upgrade i am finding the modify times on the receiving end of
the job are 2 seconds off from the sending end.
When I use 'ls -l --full-time' on the NT shares i see that all the
timestamps on the receiving e
59 matches
Mail list logo
