Extended attributes reappear when reconnecting external drive

Question

Some files on my external drive appeared grey out. Hence, I removed all the extended attributes using xattr -rc command which successfully does the trick and all my files appears normal. However, after I unplug and replug my external drive, the same set of files again appears grey out. So, to copy any file, I had to re-run the xattr command for the files each time which makes them behave like normal files.

Types of Files

All types of files like .dmg, .epub, .docx, etc appeared greyed out there is not a specific type of file as such.

Regarding extended attributes

When I completely remove all extended attributes the problem disappears. Hence, I am not aware about which particular attributed is causing the files to be greyed out.

Here is the output of ls leO@ on such greyed-out files.

-rwxr-xr-x@ 1 username  staff  -   4433605 Jul  9 22:38 xyz.dmg
    com.apple.FinderInfo           32 
    com.apple.metadata:kMDItemWhereFroms          110 
    com.apple.quarantine

-rwxr-xr-x@ 1 username  staff  -      3659 Jul  9 22:38 replug_facetime.zip
    com.apple.FinderInfo           32 
    com.apple.metadata:kMDItemWhereFroms          115 
    com.apple.quarantine           58 

-rwxr-xr-x@ 1 username  staff  -  22617886 Jul  9 22:38 robo3t-1.1.1-darwin-x86_64-c93c6b0.dmg
    com.apple.FinderInfo           32 
    com.apple.diskimages.fsck          20 
    com.apple.diskimages.recentcksum           80 
    com.apple.metadata:kMDItemWhereFroms          161 
    com.apple.quarantine           58 

Format of External Drive

NTFS; writeable initially via Mounty Software, now natively using some commands.

Here is the output of xattr -pl com.apple.FinderInfo atom-mac.zip

 com.apple.FinderInfo:
 00000000  62 72 6F 6B 4D 41 43 53 00 00 00 00 00 00 00 00  |brokMACS........|
 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
 00000020

Answer 1

The cause of the problem—or, rather, the cause of the symptoms of the problem—is indeed explained by learning the content of the extended attribute com.apple.FinderInfo. It reveals that the Finder has set the file’s file type and creator respectively to brok and MACS, signifying the file is engaged in the process of being copied and therefore cannot be accessed. (These flags are supposed to be erased upon completion of the copying process.) As a consequence, the Finder "greys out" the icons of such files to reflect their status of immutability by the user. Erasing the com.apple.FinderInfo extended attribute relieves the situation by removing the proximate cause.

The real problem, however, is the constant reassignment of this "busy being copied" status to the various files. Indeed, you specifically asked why the extended attributes reappear for particular files. My answer: I don’t know the mechanics of the events, but I do know what’s behind it.

Apple natively supports reading, but not writing, to NTFS drives. The bespoke fstab workaround method you are currently using to permit writing to the disk is known to be unstable, and is guaranteed to cause problems. (Is your username really username?) I wondered how it was you came to the abstruse idea of erasing extended attributes to correct the inaccessible file situation, and a visit to the Mounty Software site (the source of your previous workaround) showed me it was their specific recommendation. As you have learned, it is not a lasting solution. The problem will continue as long as you continue to use your current method of NTFS filesystem access.

If you must have read/write access to an NTFS formatted drive—and cannot replace it with one in the natively supported exFAT format—you will have to choose a third party offering to provide a permanent solution. Those I know of which offer acceptable usability are Tuxera, Paragon, and Fuse/NTFS3G. The first two are commercial products available on a free-trial basis; the third is a combination of two open source products.

EDIT: Response to OP's comment below

I’m sorry to say I don’t have any command line instructions which would definitely help you. I believe that the only way to fix the problem is to change the method you use for filesystem access from one which is known to have issues, as your current method does, to one which does not.

That said, I offer the following purely as an experiment, as I have no way to test it. We know that the benefit of erasing the extended attributes of the affected files only lasts until the next time the drive is mounted. It is possible that assigning a dummy value to a file’s com.apple.FinderInfo attribute will allow it to persist unmolested through the mounting process and prevent the Finder from re-assigning brok/MACS status. Specifically, this command will give a bogus file type of hack to <targetfile.ext>. Test it on just one or two of your problem files, and see what happens to them when the drive is unmounted / remounted.

xattr -wx com.apple.FinderInfo 6861636B00000000000000000000000000000000000000000000000000000000 <targetfile.ext>

(Why all the zeroes? The com.apple.FinderInfo extended attribute must be written as a single 32-byte block. Anyway, whatever it may look like here, it's one command, all on one line as you'd expect.)

Answer 2

I realize this is a partial answer, but thinking and writing it out might help us get to the answer based on additional experience with this problem.

While yes, the built-in NTFS filesystem driver might be listed as unstable, the exFAT one should be mature; I've used exFAT for years in live event production to be able to transfer powerpoint decks and audio/video content for playback between Mac & Windows systems. It always worked more or less well.

And yet, just this morning, I had the Finder in Catalina 10.15.3 failing to clear the brokMACS extended attribute after copying to a known-good exFAT-formatted drive. Blaming Mounty for providing a better solution (using a GUI to utilize the built-in 1st-party-provided filesystem driver, instead of having to install additional 3rd-party drivers, SHOULD be considered better) when it comes to mounting NTFS read/write is ignoring the real issue; the Finder NOW fails to clear temporary extended attributes on more than one filesystem driver, when it didn't used to behave this way on the type of filesystems.

Using cp commands from the Terminal seems to avoid the issue, but that doesn't fix the Finder.