https://bugzilla.samba.org/show_bug.cgi?id=2790
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|major |enhancement
Status|NEW
On Sat, Jun 11, 2005 at 02:05:48PM -0400, Erik Jan Tromp wrote:
> #0 0x08060566 in flist_find ()
> #1 0x0804c6cd in recv_generator ()
OK, the crash turned out to be caused by an empty file-list not getting
its "high" value set correctly. If such an empty list gets passed to
flist_find(), it wou
On 6/11/05, Martin Scharrer wrote:
> It would be nice if rsync would also be able to synchronise the content of a
> device, i.e.
> handle the device like a regular file. Of course only if this is requested
> with a special command line option.
The idea of a block-device-rsync comes up from time
John Van Essen wrote:
> On Sat, 11 Jun 2005, Juergen Busam <[EMAIL PROTECTED]> wrote:
>
>>Yes, the source side is a CIFS share on a NetApp filer and YES, they
>>change everytime I run rsync and they go back another hour.
>>no, they do NOT restore to their "normal" unchanged values, after
>>unmou
On Sat, 11 Jun 2005, Juergen Busam <[EMAIL PROTECTED]> wrote:
> Yes, the source side is a CIFS share on a NetApp filer and YES, they
> change everytime I run rsync and they go back another hour.
> no, they do NOT restore to their "normal" unchanged values, after
> unmounting and mounting again...
Hi list,
I often save the content of a hardware device (a harddisk partition with a
not-so-stable non-unix OS on it) on a backup disk which is connected over the
network.
Until now I used 'dd' to make a clone file of the device (dd if=/dev/hda2
of=disk.raw bs=2M) and then I copied or rsynced th
https://bugzilla.samba.org/show_bug.cgi?id=2790
Summary: mkstemp fails for paths which include extended (8-bit)
characters
Product: rsync
Version: 2.6.5
Platform: All
OS/Version: Mac OS X
Status: NEW
Sever
On Sat, 11 Jun 2005 09:03:07 -0700
Wayne Davison <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 10, 2005 at 05:14:57AM -0400, Erik Jan Tromp wrote:
> > if I remove every possible option except --fuzzy & --link-dest,
> > segfault every time.
>
> I haven't seen that in my testing. One easy thing to do i
On Fri, Jun 10, 2005 at 05:14:57AM -0400, Erik Jan Tromp wrote:
> if I remove every possible option except --fuzzy & --link-dest,
> segfault every time.
I haven't seen that in my testing. One easy thing to do is to make sure
that core dumping is enabled and look at a backtrace:
ulimit -c unlimit
Yes, the source side is a CIFS share on a NetApp filer and YES, they
change everytime I run rsync and they go back another hour.
no, they do NOT restore to their "normal" unchanged values, after
unmounting and mounting again...
they shouldn't change at all, because rsync shouldn't do anything on t
In your original "timestamps" thread back on May 25:
http://www.mail-archive.com/rsync@lists.samba.org/msg13496.html
you said the source is a "windows share from a NetApp filer" that
is mounted on a RHEL3 box via:
mount -t smbfs -o username=user,password=pwd //server/share /backup/sync
Your
http://use.perl.org/~Matts/journal/25138
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www
12 matches
Mail list logo
