On Feb 9 17:45, [EMAIL PROTECTED] wrote: > With coreutils 5.3.0-2 and various snapshots, I am seeing regressions in > shred(1)caused by cygwin changes: > [...] > $ echo a > a > $ shred --remove a > shred: a: error truncating > [...] > 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:
Ouch, ouch, ouch! I see the problem. I'm testing for > 0 where I should have tested for >= 0. This brakes ftruncate when length is set to 0. As far as fsync is affected, I don't see how that could ever fail, except the Windows call fails for some reason. The fsync code hasn't changed for quite some time. Thanks for the report, I've checked in a patch, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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/
