Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: ericblake AT comcast DOT net
To: cygwin AT cygwin DOT com
Subject: snapshots are breaking shred
Date: Wed, 09 Feb 2005 17:45:15 +0000
Message-Id: <020920051745.590.420A4C2A000CF0230000024E22058864420A050E040D0C079D0A@comcast.net>

With coreutils 5.3.0-2 and various snapshots, I am seeing regressions in shred(1)caused by cygwin changes:

1.5.12:
$ echo a > a
$ shred --remove a
$ echo $?
0
$ ls
$

20050131:
$ echo a > a
$ shred --remove a
shred: .: fsync failed: Permission denied
shred: .: fsync failed: Permission denied
$ echo $?
1
$ ls
$

20050206 and 20050208:
$ echo a > a
$ shred --remove a
shred: a: error truncating
$ echo $?
1
$ ls
a
$ uname -a
CYGWIN_NT-5.0 eblake 1.5.13s(0.118/4/2) 20050208 14:21:58 i686 unknown unknown Cygwin
$

20050206 introduced Corinna's changes to ftruncate, which might explain the current failure.  I don't know when fsync regressed between 1.5.12 and 20050131, and it is probably still broken in 20050208 since shred bypasses the final fsync on . after detecting the earlier error on ftruncate.  The following strace chunk shows that fd 3 (assigned to "./a") was open for writing as evidenced by the successful writev, so ftruncate should have succeeded instead of dying with EBADF:

   71  127064 [main] shred 13776 writev: 1024 = write (3, 0x22A2F0, 1), errno 0
  417  127481 [main] shred 13776 fhandler_base::lseek: lseek (/tmp/shred.test/a, 0, 1)
   70  127551 [main] shred 13776 fhandler_base::lseek: setting file pointer to 0 (high), 0 (low)
   68  127619 [main] shred 13776 fhandler_base::lseek: lseek (/tmp/shred.test/a, 0, 0)
   63  127682 [main] shred 13776 fhandler_base::lseek: setting file pointer to 0 (high), 0 (low)
   65  127747 [main] shred 13776 ftruncate64: -1 = ftruncate (3, 0)
  612  128359 [main] shred 13776 fhandler_base::write: binary write
shred:   573  128932 [main] shred 13776 fhandler_base::write: binary write
a: error truncating

I am also seeing the ftruncate errors when running automake, but since that invokes a perl script with many forks() before the ftruncate(), compared to the single process of shred, it was easier to use shred as the example of reproducibility during debugging.

$ automake Makefile
autom4te: cannot truncate autom4te.cache/requests at 0: Bad file descriptor
automake: autoconf failed with exit status: 1

--
Eric Blake

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/