[Bug 271925] chflags(1) fails to remove uarch flag with hardlinked files
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 271925] chflags(1) fails to remove uarch flag with hardlinked files (ZFS)"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 271925] chflags(1) fails to remove uarch flag with hardlinked files (ZFS)"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 271925] chflags(1) fails to remove uarch flag with hardlinked files (ZFS)"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 271925] chflags(1) fails to remove uarch flag with hardlinked files (ZFS)"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 271925] chflags(1) fails to remove uarch flag with hardlinked files (ZFS)"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 271925] chflags(1) fails to remove uarch flag with hardlinked files (ZFS)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 09 Jun 2023 21:48:43 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271925
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=242705&action=edit
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
--
You are receiving this mail because:
You are the assignee for the bug.