search

jdberry / tag

A command line tool to manipulate tags on Mac OS X files, and to query for files with those tags.
MIT License
1.47k stars 94 forks source link

tags created on network drive files are in a ghost state #12

Closed digitalsushi closed 8 years ago

digitalsushi commented 9 years ago

If the tag command creates a new tag on a network file/directory, that tag will not be listed under the Finder "All Tags..." until the tag command adds the same tag to a local file/directory, or the Finder adds the same tag to a local/network file/directory.

The tag created on the network resource in this scenario remains in an ephemeral state, wherein the Finder cannot delete and readd the tag. If some other process successfully adds the tag, then the ephemeral nature of the original tag is resolved.

To expound on what I mean by ephemeral, the graphics of the tag will be a dotted line instead of a solid line. I can create a similar dotted line graphic by introducing a new tag in the Finder, before the tag edit bubble is closed.

screen shot 2015-04-10 at 4 54 39 pm

I cannot find any intuition on whether this is a tag command thing, an osx thing, or both. The state machine of the tag command is a mystery! I'll understand if there's nothing to be done.

My use case here is that I drag music files/folders onto tags as genres, and then later I use your tag command to dump the tag list and assign those files/folders per tag into a playlist per tag. At home I have a mac mini in the closet with the music, which I sort from a remote client and then generate the playlists. If a new tag is introduced on the mac mini, it will not be presented on my computer until I manually munge in the tag with trickery. Thanks.

jdberry commented 9 years ago

@digitalsushi: I haven't looked into this in much detail. It looks to me like a Finder behavior, whether intentional or a bug I'm not sure.

grahamperrin commented 9 years ago

If the share point for a uniquely tagged file is at/on anything other than the startup volume of the server, then you might try the following workaround:

  1. disconnect all clients
  2. at the server, stop file sharing
  3. unmount then remount the affected volume
  4. resume sharing
  5. at the client, reconnect
  6. wait a while, see whether the uniquely tagged file appears to have that tag.

Side note

In January 2014 I fed a bug to Apple,fsck_hfs finds no error with an HFS Plus file system, but tags are not found until after a rebuild of the attributes file. Whilst I'm not aware of a conclusion, I suspect a problem with the operating system approach to working within the limitations of HFS Plus in some environments where extended attributes (EAs) are used for tags – and there may be a workaround that does not require a rebuild. Open Radar rejects AppleSeed feedback IDs so instead, I pasted some information to http://pastebin.com/S4sEdkqH and if you'd like to discuss, Ask Different Chat is good for me; http://tinyurl.com/depomme

jhein05 commented 9 years ago

Not sure if I fully understand what you are doing, but it looks like you are tagging stuff on a remote share, right? Tags heavily rely on spotlight indexing, so you need to make sure that spotlight is indexing the remote share. You can enable it with "sudo mdutil -i on /Volumes/ShareName"

digitalsushi commented 8 years ago

There's little chance this is on you, then. Let's ditch it.