search for: delete_item

https://bugzilla.samba.org/show_bug.cgi?id=12806 Bug ID: 12806 Summary: Deleting in a row of hardlinked snapshots resets file permissions. Product: rsync Version: 3.1.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

...mp; S_IWUSR) && !am_root && fp->flags & FLAG_OWNED_BY_US) + do_chmod(fname, fp->mode | S_IWUSR); if (delete_dir_contents(fname, flags | DEL_RECURSE) != DR_SUCCESS) ret = DR_NOT_EMPTY; } @@ -138,14 +138,13 @@ enum delret delete_item(char *fbuf, uint16 mode, uint16 flags) fbuf, (int)mode, (int)flags); } - if (flags & DEL_NO_UID_WRITE) - do_chmod(fbuf, mode | S_IWUSR); - if (S_ISDIR(mode) && !(flags & DEL_DIR_IS_EMPTY)) { /* This only happens on the first call to delete_...

...arnings herein): gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c rsync.c -o rsync.o rsync.c: In function `set_file_attrs': rsync.c:378: warning: unused parameter `fnamecmp' gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c generator.c -o generator.o generator.c: In function `delete_item': generator.c:216: warning: `desc' might be used uninitialized in this function generator.c: In function `unchanged_attrs': generator.c:622: warning: unused parameter `fname' generator.c: In function `itemize': generator.c:665: warning: unused parameter `fnamecmp' generator....

...ce from where the printout comes (strings replaced with "..."): (gdb) bt #0 0x9012b760 in malloc_printf () #1 0x90005f5c in free () #2 0x00037fd4 in uncache_tmp_xattrs () at xattrs.c:754 #3 0x00023c08 in make_backup (fname=0xbfffd118 "...") at backup.c:369 #4 0x0000bbb8 in delete_item (fbuf=0xbfffd118 "...", mode=33152, flags=17448) at generator.c:198 #5 0x0000b970 in delete_dir_contents (fname=0xbfffd118 "...", flags=4) at generator.c:304 #6 0x0000bab8 in delete_item (fbuf=0xbfffd118 "...", mode=16832, flags=2) at generator.c:179 #7 0x0000c2a8 i...

.... I use the modify-window=600 and cannot understand the deletion (the times on the machines are within seconds of each other). I have cranked up the verbosity level (-vvvvvv) hoping I could find something that explains why the files/folders are all being deleted. Example of the log entries: delete_item(fullpath/file) mode=100755 flags=4 I am assuming the 755 is the file permissions. I have no idea what the high order digit means. And I have no idea what flags mean. Any assistance troubleshooting this will be greatly appreciated. Leon Vanderploeg Cell 303-877-9654 -----------...

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103

...amp;& defined CAN_HARDLINK_SYMLINK @@ -1538,7 +1547,9 @@ if (remove_source_files == 1) goto return_with_success; goto cleanup; - } + } else + iflags = ITEM_REPORT_CHANGE; + recreate_symlink: /* Not the right symlink (or not a symlink), so * delete it. */ if (delete_item(fname, sx.st.st_mode, del_opts | DEL_FOR_SYMLINK) != 0) @@ -1572,18 +1583,20 @@ set_file_attrs(fname, file, NULL, NULL, 0); if (itemizing) { itemize(fname, file, ndx, statret, &sx, - ITEM_LOCAL_CHANGE|ITEM_REPORT_CHANGE, 0, NULL); + ITEM_LOCAL_CHANGE|iflags, 0, NULL); }...

Device files should be counted as devices, not symlinks. Marc. diff -aNpRruz -X /etc/diff.excludes rsync-3.2.7/delete.c devel-3.2.7/delete.c --- rsync-3.2.7/delete.c 2020-06-13 20:15:02.000000000 -0600 +++ devel-3.2.7/delete.c 2020-06-13 20:15:02.000000000 -0600 @@ -188,7 +188,7 @@ enum delret delete_item(char *fbuf, uint16 mode, uint16 flags) stats.deleted_symlinks++; #endif else if (IS_DEVICE(mode)) - stats.deleted_symlinks++; + stats.deleted_devices++; else stats.deleted_specials++; } diff -aNpRruz -X /etc/diff.excludes rsync-3.2.7/flist.c devel-3.2.7/flist.c --- rsync...

...The path of the latter may be hardcoded and it is not important to retain info about original path etc.. Not sure whether --backup or some similar option can do this just for deleted files... I was looking through the source to see if this can be hard-coded, and it seems that the function "delete_item" is where it should be done.. specifically in "do_unlink", where one could hard-code a "copy_file" to a fixed trash directory before unlink... Any suggestions?? Cheers Julian

...y changes will have an adverse or unexpected result. In my testing, it appears to be OK, but the code I'm replacing looks very deliberate. Thanks, Mike *** rsync 2.6.6/generator.c Mon Mar 12 21:04:28 2007 --- rsync 2.6.6+/generator.c Mon Apr 2 19:21:09 2007 *************** static int delete_item(char *fname, int *** 190,197 **** || (dry_run && zap_dir)) { ok = 0; errno = ENOTEMPTY; ! } else if (make_backups && !backup_dir && !is_backup_file(fname) - && !(flags & DEL_FORCE_RECURSE))...

...bility; @@ -1733,7 +1734,7 @@ fnamecmp = fname; fnamecmp_type = FNAMECMP_FNAME; - if (statret == 0 && !S_ISREG(sx.st.st_mode)) { + if (statret == 0 && !(S_ISREG(sx.st.st_mode) || (write_devices && IS_DEVICE(sx.st.st_mode)))) { if (delete_item(fname, sx.st.st_mode, del_opts | DEL_FOR_FILE) != 0) goto cleanup; statret = -1; diff -ru rsync-3.0.6/options.c rsync-3.0.6-writedev/options.c --- rsync-3.0.6/options.c 2009-04-13 08:01:14.000000000 +1200 +++ rsync-3.0.6-writedev/options.c 2009-10-...

...to return_with_success; + goto cleanup; } - /* Not the right symlink (or not a symlink), so - * delete it. */ + /* Not not a symlink, so delete it. */ if (delete_item(fname, sx.st.st_mode, del_opts | DEL_FOR_SYMLINK) != 0) goto cleanup; } else if (basis_dir[0] != NULL) { -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA co...

https://bugzilla.samba.org/show_bug.cgi?id=2645 ------- Additional Comments From dalgoda@ix.netcom.com 2005-04-24 11:36 ------- It looks like the culprit is the change for receiver.c 1.130. It pulled the call to send_file_list(-1,...), which is what handled the one_file_system code. It's not like we can easily go back either, since flist.c 1.267 removed support for f=-1. Bummer. --

I have what I believe to be a bug in the behavior of the current (2.6.4) version of rsync. While trying to upgrade from version 2.5.2 to the current version (for security concerns), I noticed the following difference in behavior between the two versions which is preventing the upgrade: If you have a directory tree on the target such as the following: dir/pdf/file1.pdf dir/pdf/file2.pdf

Hello, I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using the 3.1 kernel, I found a patch for these warnings ( http://marc.info/?l=linux-btrfs&m=131547325515336&w=2) <http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch has already been included in 3.1. Are there any other patches I can try? I''m using

...Wall -W -I./popt -c <.c> -o <.o> make rsync.c: In function `read_ndx_and_attrs': rsync.c:213: warning: `flist' might be used uninitialized in this function rsync.c: In function `set_file_attrs': rsync.c:343: warning: unused parameter `fnamecmp' generator.c: In function `delete_item': generator.c:212: warning: `desc' might be used uninitialized in this function generator.c: In function `unchanged_attrs': generator.c:555: warning: unused parameter `fname' generator.c: In function `itemize': generator.c:597: warning: unused parameter `fnamecmp' generator....

...e); @@ -1733,7 +1734,7 @@ static void recv_generator(char *fname, fnamecmp = fname; fnamecmp_type = FNAMECMP_FNAME; - if (statret == 0 && !S_ISREG(sx.st.st_mode)) { + if (statret == 0 && !(S_ISREG(sx.st.st_mode) || (copy_devices && IS_DEVICE(sx.st.st_mode)))) { if (delete_item(fname, sx.st.st_mode, del_opts | DEL_FOR_FILE) != 0) goto cleanup; statret = -1; @@ -1820,6 +1821,26 @@ static void recv_generator(char *fname, goto cleanup; } + /* On Linux systems (at least), st_size is typically 0 for devices. + * If so, try to determine the actual device size. *...

...FO, "empty dir (%s) is newer", fbuf); + rprintf(FINFO, verbose > 1 ? " (%d <= %d)\n" : "\n", check_point, attrib.st_mtime ); + } + */ + } + if (verbose > 2) { rprintf(FINFO, "delete_item(%s) mode=%o flags=%d\n", fbuf, (int)mode, (int)flags); *************** *** 1369,1374 **** --- 1396,1409 ---- stat_errno = errno; } + if ( (check_point>=0)&&(statret != 0)&&(check_point > file->modtime) ) { +...

I've just released rsync 3.0.0pre5, the latest pre-release version of the upcoming 3.0.0 release. Things are progressing well in our efforts to stamp out bugs for the final release. Please keep up the good work in testing this and sending email to the rsync mailing list with your questions, comments, bug reports, etc. Thanks! You can download the tar file and its signature from here:

I've just released rsync 3.0.0pre5, the latest pre-release version of the upcoming 3.0.0 release. Things are progressing well in our efforts to stamp out bugs for the final release. Please keep up the good work in testing this and sending email to the rsync mailing list with your questions, comments, bug reports, etc. Thanks! You can download the tar file and its signature from here: