delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2021/11/15/17:18:57

X-Recipient: archive-cygwin AT delorie DOT com
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6C754385780E
Authentication-Results: sourceware.org;
dmarc=none (p=none dis=none) header.from=spocom.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=spocom.com
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; d=spocom.com; s=mail;
h=received:date:from:to:subject:message-id:mail-followup-to
:references:mime-version:content-type:content-disposition
:content-transfer-encoding:in-reply-to:x-operating-system
:user-agent;
b=e2MtsJMEjhdbQAJT/u4Z2eujpfzmWPS/5JdozXgFEuxPQhVP5xir0gGk8GZojDafA
vkBwPPbIbOfjV+BSBD27A==
Date: Mon, 15 Nov 2021 14:18:18 -0800
From: Gary Johnson <garyjohn AT spocom DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Editing with vim clears Windows 10 file system archive bit.
Message-ID: <20211115221818.GA12715@phoenix>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <SN6PR04MB4799AEB60421601D02E22680BB979 AT SN6PR04MB4799 DOT namprd04 DOT prod DOT outlook DOT com>
<305aedc4-9bb2-02b8-f5ab-f88aba39e9cf AT t-online DOT de>
<YZK9ciahf8PDvX7A AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
In-Reply-To: <YZK9ciahf8PDvX7A@calimero.vinschen.de>
X-Operating-System: Linux 2.6.32-74-generic GNU/Linux
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED,
DKIM_VALID, SPF_HELO_NONE, SPF_PASS,
TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 1AFMIvm3000473

On 2021-11-15, Corinna Vinschen via Cygwin wrote:
> On Nov 15 19:54, Christian Franke wrote:
> > Steve Ward via Cygwin wrote:
> > > Description of problem:
> > > While using vim 8.2 on cygwin 3.3 (x86_64) on Windows 10,
> > > when editing an existing file with vim and saving it, the Window’s
> > > file system archive bit is always left cleared (not modified state).
> > > This happens, whether the archive bit was set (is modified) or
> > > clear (not modified) initially.
> > 
> > The problem also occurs with 'cp' command:
> > 
> > $ touch file1
> > 
> > $ /bin/cp file1 file2
> > 
> > $ /bin/cp --preserve=mode file1 file3
> > 
> > $ lsattr file?
> > ---a-------- file1
> > ---a-------- file2
> > ------------ file3
> > 
> > Some Cygwin functions apparently clear the archive attribute unexpectedly,
> > for example:
> > 
> > int fd = open(filename, O_CREAT|O_TRUNC|O_WRONLY, 0644);
> > write(fd, "Test\n", 5);
> > fchmod(fd, 0644); // clears archive attribute
> > close(fd);
> > 
> > Same with facl(., SETACL, ...). The variants chmod() and acl() are not
> > affected.
> 
> It's funny that it took so long that somebody actually noticed this.
> This behaviour is present at least since 2004.  Cygwin *never* actually
> cared for the ARCHIVE attribute explicitely.  The reason for the above
> observation is the open call containing the O_CREAT flag.  When Cygwin
> creates files, it sets the attributes to FILE_ATTRIBUTE_NORMAL only, not
> adding the FILE_ATTRIBUTE_ARCHIVE flag. 
> 
> Changing that is actually pretty simple, just set FILE_ATTRIBUTE_ARCHIVE
> as soon as the underlying NtCreateFile is called for an open(O_CREAT).
> 
> Fixed in current git.

I had thought that this might be a bug in Vim, so did a git bisect
to find the offending commit.  For the record, it was this one:


commit cd142e3369db8888163a511dbe9907bcd138829c
Author: Bram Moolenaar <Bram AT vim DOT org>
Date:   Thu Nov 16 17:03:45 2017 +0100

    patch 8.0.1300: file permissions may end up wrong when writing

    Problem:    File permissions may end up wrong when writing.
    Solution:   Use fchmod() instead of chmod() when possible.  Don't truncate
                until we know we can change the file.

 src/auto/configure    |  4 +--
 src/config.h.in       |  4 ++-
 src/configure.ac      |  4 +--
 src/fileio.c          | 80 ++++++++++++++++++++++++++++++++++++++++-----------
 src/os_unix.c         | 17 +++++++++--
 src/proto/os_unix.pro |  1 +
 src/version.c         |  2 ++
 7 files changed, 88 insertions(+), 24 deletions(-)


The only change I see to an open() call was removing O_TRUNC on
systems with ftruncate() and adding a later call to ftruncate() on
systems that have it.  There were also some changes to the setting
of permissions (fchown(), fchmod() and chmod()).  These changes were
all in the buf_write() function in fileio.c.

That open() call had the O_CREAT flag before and after the change.

Regards,
Gary


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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019