X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 	tests=AWL,BAYES_00,HK_OBFDOM,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: MVFS results
Date: Mon, 20 Jul 2009 15:02:28 +0000 (UTC)
Lines: 72
Message-ID:  <loom.20090720T142924-486@post.gmane.org>
References:  <loom DOT 20090715T192219-408 AT post DOT gmane DOT org> <20090715204831 DOT GA27613 AT calimero DOT vinschen DOT de> <loom DOT 20090715T213245-387 AT post DOT gmane DOT org> <loom DOT 20090717T230701-727 AT post DOT gmane DOT org> <20090718101123 DOT GA8581 AT calimero DOT vinschen DOT de>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
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

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> > Found the root cause.  R/O vs. writeable.> 
> It's not, unfortunately.  There is no code path in Cygwin's utimens
> and friends which temorarily resets the R/O attribute.  If the R/O
> attribute is actually removed temporarily, then touch calls chmod
> or something.
> 
> The core function is fhandler_disk_file.cc, fhandler_base::utimens_fs().
> It would be cool if you culd step through it to see how it behaves
> differently and examine the DOS attributes while doing that.
> What's the status code returned by the NtSetInformationFile call?

Maybe this will help:  In the 'cp -p' case, get_handle() is true, and at that 
point of cp's execution, the file is still writable (the chmod comes later).  
In the 'touch -r' case, get_handle() is false, and the file is read-only.  But 
in both cases, NtSetInformationFile has status 0.

For the 'touch -r' case, doing stat in another window shows no difference in 
the timestamp between lines 1314 and 1317; in other words, it requires closing 
the file for the time change to take effect.

So, the problem is that timestamp modification gets lost as part of fchmod 
calling NtSetAttributesFile to remove the write permissions.  Even more, my 
debugging was quite slow, with a big lag between when the file was created and 
when the fchmod took place; but rather than using the current time, the fchmod 
was able to remember the time the file was created.  I also noticed that 
NtSetAttributesFile was instantaneous - I did not have to wait for the fd to 
close to see the effects.

Is there a way to force utimens to flush pending changes to disk, short of 
closing and re-opening the fd?  Or do we teach fchmod to honor pending 
timestamp changes?

> And here's something you could try:
> 
> Index: fhandler_disk_file.cc
> ===================================================================
> RCS file: /cvs/src/src/winsup/cygwin/fhandler_disk_file.cc,v
> retrieving revision 1.302
> diff -u -p -r1.302 fhandler_disk_file.cc
> --- fhandler_disk_file.cc	16 Jul 2009 15:28:57 -0000	1.302
> +++ fhandler_disk_file.cc	18 Jul 2009 10:07:14 -0000
> @@ -1311,8 +1311,19 @@ fhandler_base::utimens_fs (const struct 
>    fbi.LastWriteTime = lastwrite;
>    fbi.ChangeTime.QuadPart = 0LL;
>    fbi.FileAttributes = 0;
> +  fbi.FileAttributes = pc.file_attributes () & ~FILE_ATTRIBUTE_READONLY;
> +  if (!fbi.FileAttributes)
> +    fbi.FileAttributes = FILE_ATTRIBUTE_NORMAL;
>    NTSTATUS status = NtSetInformationFile (get_handle (), &io, &fbi, sizeof 
fbi,
>  					  FileBasicInformation);
> +  if (NT_SUCCESS (status) && (pc.file_attributes () & 
FILE_ATTRIBUTE_READONLY))
> +    {
> +      /* Reset R/O attribute. */
> +      fbi.LastAccessTime.QuadPart = fbi.LastWriteTime.QuadPart = 0LL;
> +      fbi.FileAttributes = pc.file_attributes ();
> +      NtSetInformationFile (get_handle (), &io, &fbi, sizeof fbi,
> +			    FileBasicInformation);
> +    }

I'm not even going to bother with this patch, since 'touch -r' did just fine 
without it, and since in 'cp -p' the file is still writable at the point of the 
utimens call.

-- 
Eric Blake





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple