search for: xmit_top_dir

rsync-2.6.6 manpage says: --delete [...] This option has no effect unless directory recursion is enabled. True. In fact, I noted that --delete doesn't delete anything if --dirs is used rather than --recursive. Is there any reason for --delete not to delete when used with --dirs? Is there a way to get rsync to actually delete files on the receiving end when using

I know that there are a million messages from newbies who cannot get --delete to work. This message is special. :) --delete works fine for me EXCEPT when the following two conditions are present: 1) I am using the --relative option, and 2) the deleted file is in a subdirectory of the SRC directory. Here is a demonstration of how to recreate this bug: lenny@mythtv:/tmp$ rsync --version rsync

...t; 28) { + if (!(flags & XMIT_SAME_ATIME)) + atime = (time_t)read_int(f); + } else + atime = time(NULL); if (!(flags & XMIT_SAME_MODE)) mode = from_wire_mode(read_int(f)); @@ -624,6 +639,7 @@ file->flags = flags & XMIT_TOP_DIR ? FLAG_TOP_DIR : 0; file->modtime = modtime; + file->atime = atime; file->length = file_length; file->mode = mode; file->uid = uid; @@ -838,6 +854,7 @@ file->flags = flags; file->modtime = st.st_mtime; + file->atime = st.st_atime; file->length = st....

...t; 28) { + if (!(flags & XMIT_SAME_ATIME)) + atime = (time_t)read_int(f); + } else + atime = time(NULL); if (!(flags & XMIT_SAME_MODE)) mode = from_wire_mode(read_int(f)); @@ -638,6 +653,7 @@ file->flags = flags & XMIT_TOP_DIR ? FLAG_TOP_DIR : 0; file->modtime = modtime; + file->atime = atime; file->length = file_length; file->mode = mode; file->uid = uid; @@ -852,6 +868,7 @@ file->flags = flags; file->modtime = st.st_mtime; + file->atime = st.st_atime; file->length = st....

..._name(f, NULL)); ^ flist.c(145): remark #981: operands are evaluated in unspecified order rprintf(FINFO, "%s %11.0f %s %s\n", ^ flist.c(330): remark #810: conversion from "int" to "unsigned short" may lose significant bits flags = file->flags & XMIT_TOP_DIR; ^ flist.c(397): remark #810: conversion from "unsigned short" to "unsigned char" may lose significant bits write_byte(f, flags); ^ flist.c(398): remark #810: conversion from "int" to "unsigned char" may lose significant bit...