DO NOT REPLY [Bug 5162] using iconv with pre7 chops last special character in filenames

[samba-bugs]

https://bugzilla.samba.org/show_bug.cgi?id=5162





--- Comment #1 from [EMAIL PROTECTED]  2007-12-29 01:26 CST ---
Created an attachment (id=3081)
 --> (https://bugzilla.samba.org/attachment.cgi?id=3081&action=view)
patch for finding iconv_open under cygwin

This fixes the configure script not finding iconv_open under cygwin. Seems to
work ok on fedora 7 as well. The AM_CHECK_FUNCS with iconv_open fails because
the libiconv header redefines iconv_open to be libiconv_open. AM_CHECK_FUNCS
doesn't include iconv.h, so it fails to find the function. I'm not adept at
autoconf; there may be a better way to do this.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

DO NOT REPLY [Bug 5166] New: -o -g options don't work right or I've misread the man pages

[samba-bugs]

https://bugzilla.samba.org/show_bug.cgi?id=5166

   Summary: -o -g options don't work right or I've misread the man
pages
   Product: rsync
   Version: 2.6.6
  Platform: x86
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P3
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
 QAContact: [EMAIL PROTECTED]


I'm getting ready to transfer /home from an older slackware linux machine to a
newer ubuntu linux machine.  both are running 2.6.6 (I upgraded the older one
to match the newer one).  When I include the og options the directories and
files have the same UID and GID as on the source machine.  If I'm reading the
man pages correctly what should happen is if a file is owned by user tom group
users on the old machine the same user and group should own the file on the new
machine even if the new machine uses different UID's and GID's.

If the ownership is transferred by UID/GID and not user name/group name then
I'd like to make a suggestion that an option be added so that data can be
transferred by actual user names and group names, not by UID/GID.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

problems using --ignore-existing and filter rules

[Douglas Wade Needham]

Greetings everyone,

I have a problem which I believe is a collision between the
--ignore-existing option and filter rules.  It appears to me that
regardless of argument order, when I specify the two on a command
line, even if a non-existing directory appears in the filter list as a
protect rule.  But when I change protect rules to exclude rules, the
excluded files/directories appear not to be transferred.

Now, for details...

I have a sandbox which is a build of a complete OS image.  I want to
push the contents of this sandbox to both new and existing hosts,
protecting some files which change from server to server, as well as
protecting directory trees which are also server specific.  Sound
crazy?  It isn't.  It is a trick I used at CompuServe years ago to
build, maintain and upgrade hundreds of UN*X servers in six data
centers around the world.  And when I started having some problems
compiling rdist (lower level OS API changes), I figured to give rsync
a try.  Here is the version I found the problem with (which is in the
NetBSD pkgsrc tree).

viking$ rsync --version
rsync  version 2.6.9  protocol version 29
Copyright (C) 1996-2006 by Andrew Tridgell, Wayne Davison, and others.

Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
  inplace, IPv6, 64-bit system inums, 64-bit internal inums

The command line used is one like the following, while chroot'ed into
the sandbox, with the attached filter:

rsync -OavzHn --filter="merge /.rsync/filter.dirs" --ignore-existing / 
viking:/

I have also confirmed it on the latest versions found in FC6 and
CentOS 4.5, and 5.0.  In this case, I have copied things from under /
into a directory such as /sandbox/rsync_test, added a /.rsync
subdirectory to hold my test_rsync script and filter file, and after
adding a few extra files and creating a /opt2 by renaming /opt,
running rsync.  In each and every case, I find that /.rsync and /opt2
are transferred even if listed in a protect rule.  And this is true
regardless of whether or not the path specification start and/or ends
in a slash.

Now, as to why the protect rule vs. exclude rule is important, I want
to use the filter.dirs file to protect areas which are not a part of
the OS, such as application data, home directories and such with this
file, and then have another file protect things such as configuration
files which are a part of the OS, and should not be pushed once they
exist, but should be pushed to a server once the server is up and
running with a minimal OS load.  And so, I want to use the same filter
file I use with a command like the one above with a command such as
(untested, wrapped for readability):

 rsync -OavzH --filter="merge /.rsync/filter.dirs" 
--filter="merge /.rsync/filter.config" 
--delete-before --delete-excluded / viking:/

Now, with these details, I would love to hear if folks think that I am
crazy to think that I should be able to do this with rsync, or if the
consensis is that there indeed a bug which needs to be debugged and
exterminated?

(Now if only rsync offered a way to run commands on the remote server
when certain files were updated...hehe).

- Doug

-- 
Douglas Wade Needham - KA8ZRTUN*X Consultant & UW/BSD kernel programmer
Email:  cinnion  ka8zrt . comhttp://www.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
should my employer, or anybody else for that matter! 
#
#  Use --ignore-existing flag
#
exclude *~
protect *.orig
protect .files
protect .files.md5
protect /.rsync/
protect amd/
protect argus/
protect boot/
protect cdrom/
protect cdrom1/
protect dev/
protect distfile*
protect do_rdist.sh
protect errs*
protect floppy/
protect home/
protect homes/
protect kern/
protect mnt/
protect msdos/
protect n/
protect netbsd*
protect proc/
protect root/.Xauthority
protect root/.ksh_history
protect root/.lsof_*
protect root/.mozilla
protect root/.spamassassin
protect source/
protect sysinst.log0
protect tftpboot/
protect tmp/
protect u0/
protect u0i/
protect u0j/
protect u1/
protect u1h/
protect u2/
protect u3/
protect u4/
protect u5/
protect usr/lsrc
protect usr/mdec
protect usr/pkgsrc
protect usr/src
protect usr/xsrc
protect var/tmp/*
protect var/yp/Makefile
protect var/yp/binding
protect var/yp/ka8zrt.com
protect var/zope*
protect vol
protect work
protect www
-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Migrating Rsync Disk

[pichi]

>That's more an installation question than an rsync question...

OK thanks for your reply, but it leads me to think of how rsync works. I
don't need a huge answer but how will  server A (target) know that it has
rsync(ed) with server B if this is the first time they have talked? I mean
when I reinstall the OS and rsync, there are no more references on the
target server, and I would hate to have to do another full copy because it
took days.

Thanks,

P


-- 
View this message in context: 
http://www.nabble.com/Migrating-Rsync-Disk-tp14523326p14528964.html
Sent from the Samba - rsync mailing list archive at Nabble.com.

-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

hang with rsync 3.0.0pre7 doing local copy

[Paul Slootman]

I've noticed the 3.0.0pre versions sometimes hanging while doing a local
copy (through dirvish). This time a had a binary with debugging symbols,
so I could do gdb backtraces. This is the result:

# ps -fe | grep rsync
root  3712  3710  0 02:04 ?00:00:03 rsync -vrltH --delete -pgo 
--stats -D --numeric-ids -x --exclude-from=/backup/0/oudeserver/laatste/exclude 
--link-dest=/backup/0/oudeserver/20071225/tree /var/lib/vservers/oudeserver/ 
/backup/0/oudeserver/laatste/tree
root  3713  3712  0 02:04 ?00:00:04 rsync -vrltH --delete -pgo 
--stats -D --numeric-ids -x --exclude-from=/backup/0/oudeserver/laatste/exclude 
--link-dest=/backup/0/oudeserver/20071225/tree /var/lib/vservers/oudeserver/ 
/backup/0/oudeserver/laatste/tree
root  3714  3713  0 02:04 ?00:00:03 rsync -vrltH --delete -pgo 
--stats -D --numeric-ids -x --exclude-from=/backup/0/oudeserver/laatste/exclude 
--link-dest=/backup/0/oudeserver/20071225/tree /var/lib/vservers/oudeserver/ 
/backup/0/oudeserver/laatste/tree

# gdb -p 3712
(gdb) bt
#0  0x2ba78dcf3b63 in select () from /lib/libc.so.6
#1  0x00423ee1 in read_timeout (fd=5, buf=0x7fff1d3ac5c0 "\001", len=4) 
at io.c:653
#2  0x004243e2 in read_loop (fd=5, buf=0x7fff1d3ac5c0 "\001", len=4) at 
io.c:985
#3  0x004244d5 in readfd_unbuffered (fd=5, buf=0x7fff1d3adc70 "", 
len=1) at io.c:1022
#4  0x00424a93 in readfd (fd=5, buffer=0x7fff1d3adc70 "", N=1) at 
io.c:1144
#5  0x00425b20 in read_ndx (f=5) at io.c:1749
#6  0x0040a957 in read_ndx_and_attrs (f_in=5, iflag_ptr=0x7fff1d3afe38, 
type_ptr=0x7fff1d3afe3f "", buf=0x7fff1d3add50 "", len_ptr=0x7fff1d3afe34) at 
rsync.c:218
#7  0x004125ea in send_files (f_in=5, f_out=4) at sender.c:193
#8  0x004194f7 in client_run (f_in=5, f_out=4, pid=3713, argc=1, 
argv=0x66f240) at main.c:1045
#9  0x0041a550 in main (argc=2, argv=0x66f240) at main.c:1304

Strace says:
select(6, [5], [], NULL, {49, 42} 


# gdb -p 3713
(gdb) bt
#0  0x2ba78dcf3b63 in select () from /lib/libc.so.6
#1  0x00423ee1 in read_timeout (fd=3, buf=0x670be0 "\004", len=8184) at 
io.c:653
#2  0x00424794 in readfd_unbuffered (fd=4, buf=0x7fff1d3ad520 "¡µ\001", 
len=4) at io.c:1008
#3  0x00424a93 in readfd (fd=3, buffer=0x7fff1d3ad520 "¡µ\001", N=4) at 
io.c:1144
#4  0x00424dcf in read_msg_fd () at io.c:342
#5  0x0040fd1f in generate_files (f_out=1, local_name=) at generator.c:2089
#6  0x004190b4 in do_recv (f_in=0, f_out=1, local_name=0x0) at 
main.c:848
#7  0x004198a3 in start_server (f_in=0, f_out=1, argc=1, argv=) at main.c:958
#8  0x0041af15 in child_main (argc=490388736, argv=0x) 
at main.c:965
#9  0x00430b2e in local_child (argc=2, argv=0x7fff1d3aff00, 
f_in=0x7fff1d3b2f2c, f_out=0x7fff1d3b2f28, child_main=0x41af00 ) at 
pipe.c:150
#10 0x0041a4f9 in main (argc=2, argv=0x66f240) at main.c:464

Strace says:
select(4, [3], [], NULL, {33, 0} 

# gdb -p 3714
(gdb) bt
#0  0x2ba78dcf3b63 in select () from /lib/libc.so.6
#1  0x00423ee1 in read_timeout (fd=0, buf=0x7fff1d3a9500 "\001", len=4) 
at io.c:653
#2  0x004243e2 in read_loop (fd=0, buf=0x7fff1d3a9500 "\001", len=4) at 
io.c:985
#3  0x004244d5 in readfd_unbuffered (fd=0, buf=0x7fff1d3aabb0 "", 
len=1) at io.c:1022
#4  0x00424a93 in readfd (fd=0, buffer=0x7fff1d3aabb0 "", N=1) at 
io.c:1144
#5  0x00425b20 in read_ndx (f=0) at io.c:1749
#6  0x0040a957 in read_ndx_and_attrs (f_in=0, iflag_ptr=0x7fff1d3aed78, 
type_ptr=0x7fff1d3aed7f "", buf=0x7fff1d3acc90 "", len_ptr=0x7fff1d3aed74) at 
rsync.c:218
#7  0x00410fce in recv_files (f_in=0, local_name=0x0) at receiver.c:408
#8  0x00418fb2 in do_recv (f_in=0, f_out=1, local_name=0x0) at 
main.c:792
#9  0x004198a3 in start_server (f_in=0, f_out=1, argc=1, argv=) at main.c:958
#10 0x0041af15 in child_main (argc=490378112, argv=0x) 
at main.c:965
#11 0x00430b2e in local_child (argc=2, argv=0x7fff1d3aff00, 
f_in=0x7fff1d3b2f2c, f_out=0x7fff1d3b2f28, child_main=0x41af00 ) at 
pipe.c:150
#12 0x0041a4f9 in main (argc=2, argv=0x66f240) at main.c:464

Strace says:
select(1, [0], [], NULL, {51, 31} 

All the fds involved are sockets (pipes to one another).

As far as I can see, all processes are waiting for something to appear
on the pipes, but no one is prepared to break the silence :-)

The curious thing is that it always seems to happen at the same point in
the filesystem, last filename output is
var/lib/dovecot/ssl-parameters.dat in the cases it hangs. (Other times
that file is copied and it continues.)

This is a pretty fast system, core 2 quad with 8GB memory; perhaps
there's some race condition...


Paul Slootman
-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Odd behavior with --detect-renamed

[Erik Pettersson]

Hello,

I'm totally new to this list, so I hope I don't break all the rules. :)
I've looked through the archives (and google), and I really can't find the
answer to my question.

I'm trying out the 'detect-renamed'-patch, and I've encountered some odd
behavior. I've applied the patch to both rsync-2.6.9 and rsync-3.0.0pre7,
and it's the same behavior.

Basicly, what I've noticed is that if I move a file into a newly created
directory (which is what happens if I rename a directory, for example), the
file isn't detected as renamed. However, if I manually create the new
directory on the target-side, the file is correctly detected as a rename,
and isn't transfered over the network.

Here I've moved 'file' into a newly created directory 'dir2', which isn't
available on the target-side.

> $ find src
> src
> src/dir1
> src/dir1/dir2
> src/dir1/dir2/file
>
> $ find dst
> dst
> dst/dir1
> dst/dir1/file
>
> $ rsync -avv --detect-renamed -e ssh src/dir1 localhost:dst
> [...]
> total: matches=0  hash_hits=0  false_alarms=0 data=4544512

The file isn't detected as a rename.

If I create 'dir2' manually on the target-side, it is detected correctly:

> $ find src
> src
> src/dir1
> src/dir1/dir2
> src/dir1/dir2/file
>
> $ find dst
> dst
> dst/dir1
> dst/dir1/file
> dst/dir1/dir2
>
> $ rsync -avv --detect-renamed -e ssh src/dir1 localhost:dst
> [...]
> found renamed: dir1/file => dir1/dir2/file
> [...]
> total: matches=2136  hash_hits=2136  false_alarms=0 data=0

Is this a bug (I think so), or should it be like this?
-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Migrating Rsync Disk

[Paul Slootman]

On Fri 28 Dec 2007, pichi wrote:

> I have a Debian Etch server (Server A) running Rsync 2.6.9. In Server A I
> have a second hard drive mounted where I rsync data (about 400 GB) from
> server B.
> 
> Server A needs to be rebuilt because I didnt partition it correctly and for
> other reasons I wont get into. My question is how can I maintain my
> rsync(ed) data on the second hard drive in the new Server A without having
> to re-rsync everything again.?

That's more an installation question than an rsync question...

Make sure that when you repartition and reinstall server A, you don't
touch the second disk. After you're done installing, mount the second
disk again and continue as before.

It may be useful to first note the /etc/fstab line you use to mount the
second disk.


Paul Slootman
-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Migrating Rsync Disk

[pichi]

Hello,
I have a Debian Etch server (Server A) running Rsync 2.6.9. In Server A I
have a second hard drive mounted where I rsync data (about 400 GB) from
server B.

Server A needs to be rebuilt because I didnt partition it correctly and for
other reasons I wont get into. My question is how can I maintain my
rsync(ed) data on the second hard drive in the new Server A without having
to re-rsync everything again.?

Is that clear?

Thanks,

P.


-- 
View this message in context: 
http://www.nabble.com/Migrating-Rsync-Disk-tp14523326p14523326.html
Sent from the Samba - rsync mailing list archive at Nabble.com.

-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html