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" <killing AT multiplay DOT co DOT uk>
To: <cygwin AT cygwin DOT com>
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: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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--