Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Thu, 17 Jun 2004 09:03:58 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Problem creating files on network drives with cygwin 1.5.10-3 and tar Message-ID: <20040617070358.GB28907@cygbert.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20040616200246 DOT GA158945 AT Worldnet> <20040617011003 DOT 83544 DOT qmail AT web61006 DOT mail DOT yahoo DOT com> <20040617014728 DOT GA653435 AT hpn5170x> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040617014728.GA653435@hpn5170x> User-Agent: Mutt/1.4.2i On Jun 16 21:47, Pierre A. Humblet wrote: > On Wed, Jun 16, 2004 at 06:10:03PM -0700, Rick Rankin wrote: > > It seems to be the O_TRUNC flag that's causing the problem. If I remove it, the > > open succeeds when the file doesn't exist. > > > > Here's the output of 'strace opentest /cygdrive/m/foo | fgrep NtCreateFile' > > when /cygdrive/m/foo exists and with the O_TRUNC flag (1 line): > > > > 1081 154650 [main] opentest 1796 fhandler_base::open: 0 = NtCreateFile > > (0x32C, 40100080, m:\foo, io, NULL, 80, 7, 0, 20, NULL, 0) > > The most likely explanation is that one of your network drives does not fully > support the FILE_SUPERSEDE creation flag. Perhaps one could use FILE_OVERWRITE_IF > instead. The difference is slight and according to > http://www.osronline.com/article.cfm?id=302 > this is how CREATE_ALWAYS is implemented. CREATE_ALWAYS was used up to > 1.5.9 on NT systems. That's what the Windows DDK docs have to say about this: "The CreateDisposition value FILE_SUPERSEDE requires that the caller have DELETE access to a existing file object. If so, a successful call to ZwCreateFile with FILE_SUPERSEDE on an existing file effectively deletes that file, and then recreates it. [...] Note that this type of disposition is consistent with the POSIX style of overwriting files. [...] Overwriting a file is semantically equivalent to a supersede operation, except for the following: The caller must have write access to the file, rather than delete access. [...]" Except for Pierre's guess of the file system not supporting FILE_SUPERSEDE, there's perhaps the other possible explanation, that you don't have the DELETE permission given in the directories security descriptor. I've applied a patch which substitutes FILE_SUPERSEDE with FILE_OVERWRITE_IF in Cygwin. It shows up in the next developers snapshot. Please give it a try. Thanks for your help in tracking this down, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Co-Project Leader mailto:cygwin AT cygwin DOT 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/