search for: link_u

...ays... ------------------------------------------------------------------------ Program terminated with signal 11, Segmentation fault. #0 0x80536c0 in keep_backup (fname=0x808f060 "rsync.core") at backup.c:266 266 if (!kept && preserve_hard_links && file->link_u.links (gdb) where #0 0x80536c0 in keep_backup (fname=0x808f060 "rsync.core") at backup.c:266 #1 0x80537c9 in make_backup (fname=0x808f060 "rsync.core") at backup.c:297 #2 0x804c003 in delete_files (flist=0x8096100) at receiver.c:112 #3 0x805028c in do_recv (f_in=3, f_out=3,...

...int backup_dir_len; extern char *backup_suffix; extern char *backup_dir; +extern struct file_struct **hlink_list; extern int am_root; extern int preserve_devices; @@ -263,7 +264,7 @@ static int keep_backup(char *fname) } #endif if (!kept && preserve_hard_links && file->link_u.links - && file->F_HEAD != file) { + && hlink_list[file->F_INDEX] != file) { if (verbose > 1) rprintf(FINFO, "%s is a hard link\n", f_name(file)); } --- generator.c 22 Jan 2004 04:38:18 -0000 1.72 +++ generator.c 25 Jan 2004 09:56:10 -0000 @@ -43,...

Dear rsync people, Today I tried to back up my computer using rsnapshot with the RPM version of rsync-acl 2.6.9pre1 that I built. I tried twice, and both times, rsync encountered some kind of assertion failure. I was trying to reproduce the crash with rsync-acl 2.6.9pre2 and noticed a different bug (described below); when I have a chance, I will go back and investigate the crash further. Rsync

...le_pool, alloc_len, "receive_file_entry"); + file = *fptr = (struct file_struct *)bp; memset(bp, 0, min_file_struct_len); bp += file_struct_len; @@ -634,9 +634,9 @@ void receive_file_entry(struct file_stru file->gid = gid; #if SUPPORT_HARD_LINKS - if (idev_len) { - file->link_u.idev = (struct idev *)bp; - bp += idev_len; + if (idev_len && flist->hlink_pool) { + file->link_u.idev = pool_talloc(flist->hlink_pool, + struct idev, 1, "inode_table"); } #endif @@ -668,15 +668,19 @@ void receive_file_entry(struct file_stru #if SUPPORT_HAR...

...;length = st->st_size; + file->mode = st->st_mode; + file->uid = st->st_uid; + file->gid = st->st_gid; + if (preserve_hard_links) { + if (protocol_version < 28 ? S_ISREG(st->st_mode) + : !S_ISDIR(st->st_mode) && st->st_nlink > 1) { + if (!file->link_u.idev) { + if (!(file->link_u.idev = new(struct idev))) + out_of_memory("file inode data"); + } + file->F_DEV = st->st_dev; + file->F_INODE = st->st_ino; + } + } +#ifdef HAVE_STRUCT_STAT_ST_RDEV + if (IS_DEVICE(st->st_mode)) + file->u.rdev = st->st_rd...

Oops :) -- quote -- $ rsync -aHPv rsync://host/module/single.file . <motd, if any> receiving file list ... 1 file to consider Segmentation fault -- endquote -- The rsync process remains running until explicitly 'kill'ed. At which point, the following is printed: -- quote -- rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(225) -- endquote -- -- quote -- $ rsync -aHPv

...write_byte(f, 0); - modtime = 0, mode = 0; + modtime = 0, acctime = 0, mode = 0; dev = 0, rdev = makedev(0, 0); rdev_major = 0; uid = 0, gid = 0; @@ -379,6 +381,8 @@ else modtime = file->modtime; + acctime = file->acctime; + #ifdef SUPPORT_HARD_LINKS if (file->link_u.idev) { if (file->F_DEV == dev) { @@ -431,6 +435,8 @@ write_longint(f, file->length); if (!(flags & XMIT_SAME_TIME)) write_int(f, modtime); + if (remote_protocol >= 30) + write_int(f, acctime); if (!(flags & XMIT_SAME_MODE)) write_int(f, to_wire_mode(mode)); if (p...

...else modtime = file->modtime; + if (protocol_version > 28) { + if (file->atime == atime) + flags |= XMIT_SAME_ATIME; + else + atime = file->atime; + } #if SUPPORT_HARD_LINKS if (file->link_u.idev) { @@ -439,6 +446,8 @@ write_longint(f, file->length); if (!(flags & XMIT_SAME_TIME)) write_int(f, modtime); + if (protocol_version > 28 && !(flags & XMIT_SAME_ATIME)) + write_int(f, atime); if (!(flags & XMIT_SAME_MODE)) write_int(f, to_wire_mode(mode));...

Hi again. I just spotted another peculiarity when inspecting the rsync log. When using --compare-dest, source files that have permissions that differ from the "comparables" are not logged, unless you're using -i. Here's a testing session: $ ls -lR .: total 12 drwxr-xr-x 2 vidar users 4096 2005-03-31 14:16 cmp/ drwxr-xr-x 2 vidar users 4096 2005-03-31 14:23 dst/

I've looked around for a bug report on this problem and haven't seen one, so I apologize if this has already been discussed. I have a homegrown script which uses rsync to maintain daily backups of roughly twenty Redhat Linux systems running RH 7.2, 7.3, AS 3, and AS 4. As there are files with multiple links on the source systems, it is necessary to call rsync using the -H (--hard-links)

...else modtime = file->modtime; + if (protocol_version > 28) { + if (file->atime == atime) + flags |= XMIT_SAME_ATIME; + else + atime = file->atime; + } #if SUPPORT_HARD_LINKS if (file->link_u.idev) { @@ -443,6 +450,8 @@ write_longint(f, file->length); if (!(flags & XMIT_SAME_TIME)) write_int(f, modtime); + if (protocol_version > 28 && !(flags & XMIT_SAME_ATIME)) + write_int(f, atime); if (!(flags & XMIT_SAME_MODE)) write_int(f, to_wire_mode(mode));...

...me)); ^ generator.c(204): remark #981: operands are evaluated in unspecified order rsyserr(FERROR, errno, "delete_file: rmdir %s failed", ^ generator.c(663): remark #810: conversion from "int" to "unsigned short" may lose significant bits file->link_u.links->link_dest_used = j + 1; ^ generator.c(681): remark #981: operands are evaluated in unspecified order full_fname(cmpbuf), fname); ^ generator.c(680): remark #981: operands are evaluated in unspecified order rsyserr(FINFO, errn...