Mail Archives: cygwin/2005/02/14/16:22:43
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/
- Raw text -