Re: Problem creating files on network drives with cygwin 1.5.10-3 and tar

[Rick Rankin <rick_rankin at yahoo dot com>]

--- Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 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.

Corinna,

Thanks for making the change so quickly! The 0617 snapshot definitely fixed the
tar problem. I don't know if it makes a difference for the internal change you
make, but I am able to delete files on that share, both with Cygwin and native
Windows commands, so the CREATE_ALWAYS flag should have worked as well.

I should mention that I've noticed what appears to be a completely unrelated
side effect in this snapshot. The initial symptom I noticed was that my bash
prompt no longer had the proper colors. I have some code in my .bashrc file to
add color to my prompt:

export SO="$(tput sgr0)$(tput setaf 7)$(tput setab 4)"
export SE="$(tput sgr0)"
export PS1='${SO}[\u@\h:\W]${SE}\n$ '

After installing the snapshot, the color disappeared from my prompt, but
reappeared when I went back to the stock 1.5.10-3 DLL. After fooling around
with it a bit, I noticed that the problem seems to involve pipes in general,
but not in all circumstances. For example, with the snapshot,

echo $(cygpath -w -t mixed /)

echos nothing, but

echo $(uname)

seems to work. Both work properly in 1.5.10-3. The command 'tput clear' does
nothing with the 0617 snapshot but works with 1.5.10-3. I also have some
ActiveState perl scripts that run some Cygwin commands in a pipe and read the
output. The scripts I've tried so far are failing with the 0617 snapshot. 

FYI, I just tried the 0616 snapshot and it has all the same symptoms.

Hopefully, you can reproduce this one. If you can't, let me know what I can do
to help.

Rick




--
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/