From: Gary Johnson <garyjohn@spocom.com>
To: cygwin@cygwin.com
Subject: Re: Editing with vim clears Windows 10 file system archive bit.
Date: Mon, 15 Nov 2021 14:18:18 -0800 [thread overview]
Message-ID: <20211115221818.GA12715@phoenix> (raw)
In-Reply-To: <YZK9ciahf8PDvX7A@calimero.vinschen.de>
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@vim.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
next prev parent reply other threads:[~2021-11-15 22:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-14 18:56 Steve Ward
2021-11-15 18:54 ` Christian Franke
2021-11-15 20:05 ` Corinna Vinschen
2021-11-15 22:18 ` Gary Johnson [this message]
2021-11-16 14:06 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211115221818.GA12715@phoenix \
--to=garyjohn@spocom.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).