I'm trying to rsync (with -a to preserve permissions) to a mount point on an NFS server, and it fails when copying a file that is read-only. The problem is that do_mkstemp creates the temp file with the desired user permissions (either with open() or with fchmod(). SUSv3 says that the affect of chmod()/fchmod() on existing open file descriptors is implemtation defined; it also says: Any file descriptors currently open by any process on the file could possibly become invalid if the mode of the file is changed to a value which would deny access to that process. One situation where this could occur is on a stateless file system. This behavior will not occur in a conforming environment. I guess I have a non-conforming environment (I'm talking to a unfs3 server). If I remove HAVE_FCHMOD, it still doesn't work, because the call to open() includes the read-only permissions as well (a case I don't really see referenced in SUSv3 right off). The following patch makes sure that the user always has write permission to the temp file: diff -urN rsync-2.6.9-dist/syscall.c rsync-2.6.9/syscall.c --- rsync-2.6.9-dist/syscall.c 2007-10-19 20:49:29.000000000 -0500 +++ rsync-2.6.9/syscall.c 2007-10-19 20:53:02.000000000 -0500 @@ -190,6 +190,7 @@ { RETURN_ERROR_IF(dry_run, 0); RETURN_ERROR_IF(read_only, EROFS); + perms |= S_IWUSR; #if defined HAVE_SECURE_MKSTEMP && defined HAVE_FCHMOD && (!defined HAVE_OPEN64 || defined HAVE_MKSTEMP64) {
Created attachment 2947 [details] Make sure the user has write permission to the temp file
I checked that the callers of do_mkstemp() will all fix the permissions if the user-write permission is not supposed to be on final file, and it looks good. I've checked your patch into CVS. Thanks!