From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32001 invoked by alias); 26 Apr 2011 15:10:26 -0000 Received: (qmail 31991 invoked by uid 22791); 26 Apr 2011 15:10:24 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Apr 2011 15:10:07 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QEjtt-00086X-4b for cygwin@cygwin.com; Tue, 26 Apr 2011 17:10:05 +0200 Received: from c-98-222-62-135.hsd1.il.comcast.net ([98.222.62.135]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2011 17:10:05 +0200 Received: from dan by c-98-222-62-135.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2011 17:10:05 +0200 To: cygwin@cygwin.com From: Dan Grayson Subject: Re: untarring symlinks with ../ fails randomly Date: Tue, 26 Apr 2011 15:54:00 -0000 Message-ID: References: <20110424121145.GB30696@calimero.vinschen.de> <20110426074325.GP3324@calimero.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-04/txt/msg00361.txt.bz2 (Re-posting yet again, didn't get through yesterday or today (?), this time from a different account.) Corinna, Debugging with gdb shows that "tar" is prepared for the possibility that symbolic links don't work and that hard links will have to be used instead. So, when it encounters a symbolic link, it creates a zero-length file with mode 0 as a placeholder, and it records the inode number of the new file. That way it can wait until all the regular files have been created, and then replace the placeholder by a symbolic link, or if that doesn't work, by a hard link to the existing file. However, a tar file can contain multiple entries corresponding to the same file name or path, so it may happen that the placeholder is no longer present at the end, having been replaced by another file. Hence, it will only replace the placeholder if the inode number and the creation time are unchanged. But, under cygwin, the creation time may change gratuitously after the creation of the file, at random! Hence the placeholder is sometimes left in place. My system is Windows 7. Here is a C program (simple test case) that illustrates it. #include #include #include #include #include int main () { static struct stat s; int i; char * fn [12] = { "tmpdir/a","tmpdir/b","tmpdir/c","tmpdir/d","tmpdir/e","tmpdir/f", "tmpdir/g","tmpdir/h","tmpdir/i","tmpdir/j","tmpdir/k","tmpdir/l" }; struct timespec ctime[12]; mkdir("tmpdir",0755); for (i=0; i<12; i++) { int fd = open(fn[i],O_EXCL|O_CREAT|O_WRONLY,0); fstat(fd,&s); ctime[i] = s.st_ctim; close(fd); } sleep(1); for (i=0; i<12; i++) { struct timespec ctime2; stat(fn[i],&s); ctime2 = s.st_ctim; if (ctime[i].tv_nsec != ctime2.tv_nsec) printf("ctime changed: file %s, %lu.%09lu -> %lu.%09lu\n", fn[i], ctime[i].tv_sec, ctime[i].tv_nsec, ctime2.tv_sec, ctime2.tv_nsec); } return 0; } Here is some sample output from the program. $ rm -rf tmpdir && gcc -Wall p.c && ./a.exe ctime changed: file tmpdir/c, 1303742293.177618900 -> 1303742293.178619000 ctime changed: file tmpdir/f, 1303742293.178619000 -> 1303742293.179619000 ctime changed: file tmpdir/h, 1303742293.179619000 -> 1303742293.180619100 ctime changed: file tmpdir/k, 1303742293.180619100 -> 1303742293.181619100 -- 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