Editing with vim clears Windows 10 file system archive bit.

[Gary Johnson]

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