delorie.com/archives/browse.cgi | search |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |