5

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
5
  • @GordonDavisson I have updated the question. If you are a moderator then can you please migrate the question to AskDifferent if it seems to be appropriate there. I posted the question here because of a [related question][1] already existing on this site [1]: stackoverflow.com/questions/4833052/… – geeksal Jul 10 '18 at 5:10
  • 2
    I don't have that privilege, but I've flagged it for someone who does. As for the question itself, I can't say for sure but my money's on this being a bug in the Mounty software you're using to get write access to NTFS. – Gordon Davisson Jul 10 '18 at 6:07
  • It might help to know the contents of the FinderInfo attribute for a few of these troublemakers. If you're willing, please edit your question to add the results of the following command on two or three greyed-out files: xattr -pl com.apple.FinderInfo <filename.ext> – Doc G. Jul 20 '18 at 1:52
  • 2
    @DocG. I have updated the question to include the output of xattr -pl command. Please check and reply. – geeksal Jul 21 '18 at 14:04
  • @cjk: The files in the output example, plus those listed under the "Types of Files" heading, are either themselves compressed files or typically contain compressed files somewhere in their bundles. – Doc G. Jul 22 '18 at 23:18
7

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.)

6
  • 1
    I think you got the problem. That's great. Can I mitigate somehow by terminal commands or something???? Except for any commercial software. My username is not username it just for example. Previously I used Mounty and it was causing some problems hence I shifted to fstab method. The software you listed are already known to me. I hope that you can find some way either by Mac, Linux or Windows to mitigate this behavior. I use all of the three hence I require NTFS as it is a good file system. – geeksal Jul 23 '18 at 9:12
  • 2
    +1 for your hack. Its working but still, I have a problem with one of the files. Here is the output of xattr -pl com.apple.FinderInfo for this file 00000000 68 61 63 6B 00 00 00 00 00 00 00 00 00 00 00 00 |hack............| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 Can you figure out what is the problem with this?? Your hack is not working here. If you solve this then I will definitely mark your answer as accepted. – geeksal Jul 26 '18 at 15:01
  • 1
    I see nothing listed in the above except for the change I suggested. If the file is still greyed out, then my experiment failed and I apologize for wasting your time. – Doc G. Jul 26 '18 at 23:00
  • 1
    Hey you do not need to apologize. Even if one of type of my files is still greyed out I will research and find it out myself or take the help from the guys who really know what is going on. By the way, you saved me lots of time. Be happy ;) – geeksal Jul 28 '18 at 18:44
  • 1
    Thank you. Remember that since the nature of the problem has changed, you are welcome to ask a new question describing which type of file is still affected, which types were fixed, and any other new information. – Doc G. Jul 28 '18 at 20:50
-1

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.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .