The TL;DR answer is that this is probably a Microsoft bug. 0x10 seems to be one of the FreeBSD file security flags defined as UF_NOUNLINK ("file may not be removed or renamed"). These mostly serve a similar purpose to System Integrity Protection. OneDrive may be setting this to prevent users removing files in the OneDrive-managed folders, but the source code in <sys./stat.h> says this is not implemented in MacOS. Hence the "invalid bsd_flags" error. Meanwhile there's also a parameter UF_SETTABLE=0xffff which is used by MacOS to limit which flags can be set. This means it's possible to set the 0x10 bit even though it generates this error later.
So it looks like there are two bugs:
1. Microsoft OneDrive may be setting this based on the flag from BSD, but this is not valid for MacOS
2. There's also an Apple bug in that 0x10 should probably be excluded 0x10 from UF_SETTABLE to prevent this getting set by mistake
In the meantime if disk utility completes with only a warning then you *may* be able to ignore this. Also, it may be possible to clear the flag in a terminal window without reinstalling as follows:
a. Type "ls -lOd /path/to/file" (that's the letter O, not zero)
b. If the 5th column only has 0x10 or similar and not word(s) such as "hidden" then proceed to (c):
b. Type: "chflags 0 /path/to/file"
You can see examples of some other flags in place with "ls -lOd /*". Note that "chflags 0 ..." will remove all permitted flags, which is why you need to check there are not any other existing flags in (b). [Also I have not tested this; some flags cannot be unset without booting into single user mode].
From <sys/stat.h> in the source code:
#define UF_SETTABLE 0x0000ffff /* mask of owner changeable flags */
/*
* The following bit is reserved for FreeBSD. It is not implemented
* in Mac OS X.
*/
/* #define UF_NOUNLINK 0x00000010 */ /* file may not be removed or renamed */
[doublepost=1551058461][/doublepost]
I do not know if this may or not help to explain part of the meaning of that strange message.
On some occasions I tried with little luck to use MacOS's Disk Utility to repair my Bootcamp Windows volume.
I did it because of a message telling the volume had to be repaired but, as I said, it never helped.
On those occasions Disk Utility's repair brought a long list of real or supposed errors and every sentence mentioned the "Inode" word found in this message.
I do not know what an "Inode" might be but wiser people might know it.
However these Inode problems were mentioned only regarding Windows and never when a MacOS volume underwent repair.
(For MacOS repairs I use Disk Warrior, an app which proved to me very useful and has to be started from an external volume in order to repair the inner one).
Ed
An "inode" is essentially a file. Unix (including MacOS) has two levels of directory in the filesystem:
1. The hierarchical folders visible as directories just contain pairs of "filename1 number1", "filename2 number2", etc.
2. Each of these numbers is the index of an entry in a flat "inode table". The inode contains all of the real information about the file including owner/group, dates, size, permissions (including these bsd_flags), and pointers to the actual data blocks of the file
So in many ways the inode is the actual file, just like you might have two names in a phone directory but only one actual phone number (and phone).
You can see the inode numbers in a terminal with "ls -l" or "find -ls", but the numbers are not normally useful except when you have a warning like this.
When Disk Utility checks the disk it checks the inode table in a separate pass from checking the directories with the names, so when it reports this error it does not actually know what name this file has in the filesystem.
