Date: Sun, 1 Jan 2006 00:10:07 GMT From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/91134: [PATCH] Preserve access and modification time when cp to a smbfs destination path Message-ID: <200601010010.k010A7PE022563@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/91134; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Gilbert Cao <hika@bsdmon.com> Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/91134: [PATCH] Preserve access and modification time when cp to a smbfs destination path Date: Sun, 1 Jan 2006 11:06:48 +1100 (EST) On Sat, 31 Dec 2005, Gilbert Cao wrote: >> Fix: > The following patch has fixed the problem as I have finally found the problem in > the src/bin/cp source code, especially the utils.c file : > I have found out that utimes() does nothing on the newly created file, if its > file descriptor is not closed yet, and this is only the case in a SMB destination path. This is a bug in smbfs. cp only works on POSIX file systems. > --- patch_cp_utils.diff begins here --- > --- ./src/bin/cp/utils.c.orig Sat Nov 12 22:21:45 2005 > +++ ./src/bin/cp/utils.c Fri Dec 30 19:23:04 2005 > @@ -204,8 +204,6 @@ > * to remove it if we created it and its length is 0. > */ > > - if (pflag && setfile(fs, to_fd)) > - rval = 1; > if (pflag && preserve_fd_acls(from_fd, to_fd) != 0) > rval = 1; > (void)close(from_fd); > @@ -213,6 +211,14 @@ > warn("%s", to.p_path); > rval = 1; > } > + /* > + * To preserve times in SMB to.p_path, > + * setfile() should be call *AFTER* we have closed the file > + * descriptors. As we have closed the descriptors, we should > + * pass -1 instead of the `to_fd` value > + */ > + if (pflag && setfile(fs, -1)) > + rval = 1; > return (rval); > } It can't be right to always close the file. This leaves the fd >= 0 case in setfile() unused and bogotifies all the code that handles this case, even for POSIX file systems where this code just works. However, I can't see any reason to have the fd >= 0 case except to avoid minor races for regular files only. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601010010.k010A7PE022563>