Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject: Re: snapshots are breaking shred
Date: Mon, 14 Feb 2005 21:19:28 +0000 (UTC)
Lines: 36
Message-ID: <loom.20050214T215335-693@post.gmane.org>
References: <020920051745 DOT 590 DOT 420A4C2A000CF0230000024E22058864420A050E040D0C079D0A AT comcast DOT net> <20050209192812 DOT GU2597 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet AT sea DOT gmane DOT org
X-Gmane-NNTP-Posting-Host: main.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 128.170.36.44 (Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322))
X-Gmane-MailScanner: Found to be clean
X-Gmane-MailScanner: Found to be clean
X-MailScanner-From: goc-cygwin AT m DOT gmane DOT org
X-MailScanner-To: cygwin AT cygwin DOT com
X-IsSubscribed: yes

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/