Corinna Vinschen <corinna-cygwin <at> cygwin.com> 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 POSIX. http://www.opengroup.org/onlinepubs/009695399/functions/fsync.html -- 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/
