X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org X-MDAV-Processed: mail1.multiplay.co.uk, Fri, 07 Jan 2011 18:20:50 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 07 Jan 2011 18:20:50 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=19881e9a8d=killing AT multiplay DOT co DOT uk X-Envelope-From: killing AT multiplay DOT co DOT uk X-MDaemon-Deliver-To: cygwin AT cygwin DOT com Message-ID: <3501944D149644D394474781054F5E98@multiplay.co.uk> From: "Steven Hartland" To: Subject: Strange fstatat / stat behavour on directories causing tar "file changed as we read it" error Date: Fri, 7 Jan 2011 18:21:02 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01C7_01CBAE97.A40AB150" X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com ------=_NextPart_000_01C7_01CBAE97.A40AB150 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Just been debugging a very strange issue where tar was reporting "file changed as we read it" for directories which aren't actually seeing any changes. It turns out that the value of st_size returned by a call to fstatat on a directory can change even though there have been no changes at all to said directory or its children. It seems that purely looking in a directory will change the "size" value reported by fstatat and likely stat. For a directory which hasn't been traversed / looked in its size is 0 where as after its been looked in it tends to report 8192. The result is that tar which checks for consistency of the data its archiving errors (although soft error) when archiving a directory as on initial access its size is 0 but after compressing all the files in said dir and hence looking in that directory its size is 8192. The attached patch fixes this strange behaviour by ignoring size changes for directories as well as correcting the file size check to also detect file shrinks as well as growths, which seemed very odd. Is there some "meta data" caching going on in cygwin or Windows which causes this very strange behaviour? Regards Steve ------=_NextPart_000_01C7_01CBAE97.A40AB150 Content-Type: application/octet-stream; name="tar-src-create.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="tar-src-create.c.patch" --- src/create.c.orig 2011-01-07 10:04:33.297364800 -0800 +++ src/create.c 2011-01-07 09:51:37.804364800 -0800 @@ -1788,7 +1788,7 @@ /* Original ctime will change if the file is a directory and --remove-files is given */ && !(remove_files_option && is_dir)) - || original_size < final_stat.st_size) + || (!is_dir && original_size !=3D final_stat.st_size)) { WARNOPT (WARN_FILE_CHANGED, (0, 0, _("%s: file changed as we read it"), ------=_NextPart_000_01C7_01CBAE97.A40AB150 Content-Type: text/plain; charset=us-ascii -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ------=_NextPart_000_01C7_01CBAE97.A40AB150--