snapshots are breaking shred

Eric Blake
Tue Feb 15 06:06:00 GMT 2005

Corinna Vinschen <corinna-cygwin <at>> writes:
> > With coreutils 5.3.0-2 and various snapshots, I am seeing regressions in 
shred(1)caused by cygwin changes:
> 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.

I found what is causing this.  Coreutils shred uses the following code:
int dir_fd = open (dir, O_WRONLY | O_NOCTTY);
if (dir_fd < 0)
  dir_fd = open (dir, O_RDONLY | O_NOCTTY);
fsync (dir_fd);

POSIX requires that open fail with EISDIR on open with O_WRONLY or O_RDWR on a 
directory, and you implemented that in a patch on Jan 6.  So with 1.5.12, shred 
got a writeable fd from the first open, but with snapshots after Jan 6 it has 
only a readable fd from the second open.  But fsync() is implemented with 
FlushFileBuffers, which requires write access to the handle it is about to 
flush, so it now fails with EACCES.

I don't know if it is better to patch open_fs() to additionally grant 
GENERIC_WRITE access when opening directories as O_RDONLY (since that is the 
only way to open a directory), or to patch fsync() to temporarily grant write 
access to a directory for the duration of the flush.  But it is a definite 
regression from 1.5.12 that should be fixed.

I also think that fsync() could be patched to return EINVAL on non-directory 
file descriptors that were opened as O_RDONLY, rather than performing a failed 
FlushFileBuffers and getting EACCES, as a closer match to the errors allowed by 

Eric Blake

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list