search for: set_file_attr

...fe_symlinks && unsafe_symlink(sl, fname)) { if (verbose) { @@ -1528,7 +1529,15 @@ else if ((len = readlink(fname, lnk, MAXPATHLEN-1)) > 0 && strncmp(lnk, sl, len) == 0 && sl[len] == '\0') { /* The link is pointing to the right place. */ - set_file_attrs(fname, file, &sx, NULL, maybe_ATTRS_REPORT); + if (inplace) { + if (verbose > 2) + rprintf(FINFO, "possibly tweaking attributes of %s\n", fname); + set_file_attrs(fname, file, &sx, NULL, maybe_ATTRS_REPORT); + } else if (!unchanged_attrs(fname, file, &sx...

...ttrs(int f_in, int *if void free_sums(struct sum_struct *s); mode_t dest_mode(mode_t flist_mode, mode_t stat_mode, int dflt_perms, int exists); +void make_mutable(const char *fname, mode_t mode, uint32 fileflags); +void undo_make_mutable(const char *fname, mode_t mode, uint32 fileflags); int set_file_attrs(const char *fname, struct file_struct *file, stat_x *sxp, const char *fnamecmp, int flags); RETSIGTYPE sig_int(UNUSED(int val)); @@ -296,6 +298,7 @@ int do_mknod(const char *pathname, mode_ int do_rmdir(const char *pathname); int do_open(const char *pathname, int flags, mode_t mode); int...

...on't be forgotten.] When --perms is off, an incoming chmod of "Dg-s" does not prevent new directories on the receiver from inheriting setgid bits; it probably should. Incoming chmod currently takes effect in dest_mode, which is too soon for it to affect the directory setgid check in set_file_attrs. To avoid further bugs of this nature, I propose that incoming chmod should take effect right before the actual call to chmod in set_file_attrs, as rsyncd-perm once did. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------...

...;t check for negative values provided in file1 or file2. If file2 is positive, and file1 is negative, and absolute_value(file1) > file2, cmp_time returns 0, even though the times are obviously different. Of course, a file's crtime should never be negative, which leads me to #2. 2) set_file_attrs (rsync.c) doesn't initialize sx2.crtime (e.g. when the sxp argument is NULL). This leads to crtime values that are occasionally > 2^31, resulting in negative crtimes. The attached patch resolves these. Mike -------------- next part -------------- A non-text attachment was scrubbed.....

...has the bad habit of considering a rename on an UDF FS as a file change; that is: > touch -t 201010101010 test > ls -l test -rw-r--r-- 1 gui staff 0 10 oct 2010 test > mv test fail > ls -l fail -rw-r--r-- 1 gui staff 0 29 nov 00:19 fail rsync.c (3.1.2), in archive mode, calls set_file_attrs *before* renaming .file.XXXXXX to file. So, in the aforementioned case, all times beautifully crafted on the file get lost. I would be glad to know if other OSes / FS combinations get such a disturbing implementation. Could this behavior be ground to an rsync enhancement request? In this cas...

...sx.st.st_flags is initialized in flist.c:send_file_name() so get_xattr has access to fileflags - rsync.c: Errors that occur in undo_make_mutable are now reported (I think this also resolves an issue in which rsync would report "Unknown error (0)") - rsync.c: make_mutable is now called in set_file_attrs allowing set_file_attrs to apply acls, xattrs, times, etc. to files in locked directories. - syscall.c: Added make_mutable/force_change functionality to many of these system calls -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because...

...Each undeclared identifier is reported only once flist.c:1654: for each function it appears in.) Other notes: from 3.0.8 (using flist.c from 3.0.7 for convenient reporting of other warnings 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 `un...

...d 1). I can not replicate the problem, but I suspect the file was modified (or removed) while rsync was running (the rsync take ~30 minutes). I checked the code, and noticed that before "rsync" commit the temp file (finish_transfer @ rsync.c), it changes the file attributes (using 'set_file_Attrs'). However, it does not check if the file attributes were updated succesfully. As a result, it may leave files with the wrong timestamp/ownership or permission. My suggested solution is to modify set_file_perms- return 0 for no change, 1 for changes and -1 for error. finish_transfer can than...

When rsync'ing to an Ext2 file system (via SSH), then I frequently get error messages such as "failed to set times ...". AFAICS, these error messages are caused by rsync trying to change the time (and permissions, ownership) of symbolic links, which according to my knowledge is not possible on Ext2. Is there any way to get rid of these supposedly superfluous error messages? rsync

...rsyserr(FERROR_XFER, errno, "symlink %s -> \"%s\" failed", + full_fname(fnametmp), sl); + goto cleanup; + } + set_file_attrs(fnametmp, file, NULL, NULL, 0); + if (do_rename(fnametmp, fname) != 0) { + rsyserr(FERROR_XFER, errno, "rename %s -> %s failed", + full_fname(fnametmp), full_fname(fname))...

...ned int format, uint32_t arg (arg 4) flist.c:2655: warning: unsigned int format, uint32_t arg (arg 5) flist.c:2655: warning: unsigned int format, uint32_t arg (arg 5) flist.c:2659: warning: int format, int32_t arg (arg 4) flist.c:2659: warning: int format, int32_t arg (arg 4) rsync.c: In function `set_file_attrs': rsync.c:455: warning: unsigned int format, uint32_t arg (arg 5) rsync.c:460: warning: unsigned int format, uint32_t arg (arg 5) receiver.c: In function `receive_data': receiver.c:227: warning: int format, int32_t arg (arg 3) receiver.c:252: warning: int format, int32_t arg (arg 3) send...

...BSD RELENG_4 untar 3.0.0pre10 ./configure yields these arguments gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -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...

...-0600 @@ -35,6 +35,8 @@ extern int preserve_executability; extern int preserve_mtimes; extern int omit_dir_times; extern int omit_link_times; +extern int omit_device_times; +extern int omit_special_times; extern int am_root; extern int am_server; extern int am_daemon; @@ -578,7 +580,9 @@ int set_file_attrs(const char *fname, struct file_struct *file, stat_x *sxp, #endif if ((omit_dir_times && S_ISDIR(sxp->st.st_mode)) - || (omit_link_times && S_ISLNK(sxp->st.st_mode))) + || (omit_link_times && S_ISLNK(sxp->st.st_mode)) + || (omit_device_times && IS_DEV...

...n rsyncing a to b with - at -1, it should recognize the mtimes as different, attempt to change b, and fail. However, no error is reported, and the -i output shows that the operation was completed as instructed -- which, of course, it could not have. The reason here is that, as far as I can see, in set_file_attrs, ATTRS_SET_NANO is not given and no attempt to set the mtime is made. Later however, in touch_up_dirs, set_modtime is called on the directory. It fails, but there is no error handling, because usually, the mtime would already have been set before, and an error would have become apparent already. (...

...ion in util.c, one can clearly see that rsync developers take a very sane and reasonable approach by declaring mod_nsec as an uint32 -- that is, both unsigned, and having a byte-fixed reasonable size. ( This is imho how tv_nsec field should have been declared! ) Furthermore, rsync 3.1.1 -- see set_file_attrs() in rsync.c -- compares only mtime _seconds_, and takes no attempt to adjust mtimes further if the "classic" .st_mtime values coincide. ( And this is why all the "Invalid argument (22)" problems disappear after we transfer .st_mtime values by an utime() call. ) Therefor...

https://bugzilla.samba.org/show_bug.cgi?id=7865 Summary: files or dirs with more than 16 ACLs are not rsynced correctly Product: rsync Version: 3.0.7 Platform: IA64 OS/Version: HP-UX Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org

...e_sums(struct sum_struct *s); > mode_t dest_mode(mode_t flist_mode, mode_t stat_mode, int dflt_perms, > int exists); > +int make_mutable(const char *fname, mode_t mode, uint32 fileflags, > uint32 iflags); > +int undo_make_mutable(const char *fname, uint32 fileflags); > int set_file_attrs(const char *fname, struct file_struct *file, > stat_x *sxp, > const char *fnamecmp, int flags); > RETSIGTYPE sig_int(UNUSED(int val)); > @@ -293,11 +295,12 @@ int sock_exec(const char *prog); > int do_unlink(const char *fname); > int do_symlink(const char *fname1, cons...

...gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c flist.c -o flist.o gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c rsync.c -o rsync.o rsync.c: In function `read_ndx_and_attrs': rsync.c:215: warning: `flist' might be used uninitialized in this function rsync.c: In function `set_file_attrs': rsync.c:341: 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 `unchanged_attrs': generator.c:518: warning: unused parameter `fname' generator.c: In function `itemize': generator.c...