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 <b...@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
--
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
