Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 09 Jun 2023 21:48:43 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 271925] chflags(1) fails to remove uarch flag with hardlinked files
Message-ID:  <bug-271925-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271925

            Bug ID: 271925
           Summary: chflags(1) fails to remove uarch flag with hardlinked
                    files
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: jamie@catflap.org

Created attachment 242705
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D242705&action=
=3Dedit
terminal output demonstrating the problem

Using chflags to remove "uarch" on more than one file at a time
(but when that file count is an even number) when the files are
hardlinked (have the same inode) and on ZFS doesn't work.

This becomes more problematic when using "find... -exec chflags nouarch {} =
+"
or "chmod -R".

The problrem occurs because if chflags(2) resets uarch on a file
which doesn't already have uarch set, then the very update causes
uarch to be set.

To mitigate that, chflags(1) does a stat of the file, and will only
attempt to remove the flag if it actually exists.

The problem here is that the stat operation is done on all files
before the chflag(2) operation is then applied to all files.

Apart from the fact this introduces generally a race condition,
it means in this specific case that the flag is removed, and then
added again. (A sort of race against itself that it always loses!)

The stat(2) and chflags(2) should be as close together as possible,
to keep the operation as atomic as possible.

If that is unacceptable due to inefficiencies, chflags(1) should
at least ignore files that it stats which have the same inode as
another file previously stat(2)'ed

A demonstration, along with a ktrace of the offending part of the
code is attached.

Cheers, Jamie

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271925-227>