Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #68734 > unrolled thread

Problems with Spotlight comments

Back to article view | Back to comp.sys.mac.system

Contents

  Problems with Spotlight comments isw <isw@witzend.com> - 2015-01-22 21:51 -0800
    Re: Problems with Spotlight comments -- Solved isw <isw@witzend.com> - 2015-01-24 21:48 -0800
      Re: Problems with Spotlight comments -- Solved Jolly Roger <jollyroger@pobox.com> - 2015-01-25 14:55 +0000
        Re: Problems with Spotlight comments -- Solved Ant <ant@zimage.comANT> - 2015-01-25 12:05 -0800
          Re: Problems with Spotlight comments -- Solved nospam <nospam@nospam.invalid> - 2015-01-25 15:42 -0500
            Re: Problems with Spotlight comments -- Solved Jolly Roger <jollyroger@pobox.com> - 2015-01-25 21:00 +0000
              Re: Problems with Spotlight comments -- Solved Ant <ant@zimage.comANT> - 2015-01-25 13:48 -0800
                Re: Problems with Spotlight comments -- Solved Jolly Roger <jollyroger@pobox.com> - 2015-01-25 22:08 +0000

#68734 — Problems with Spotlight comments

I'm currently trying to deal with a whole lot of files (>20k) which have 
been tagged using Spotlight comments. The files in question are not on 
my system disk, but on another local disk which is mounted at all times; 
I don't know if that matters.

Some of the files do not show up using Spotlight to search on comments, 
despite the fact that I can see the comments if I do a "get info" on the 
files.

Some of the files show up when I execute a search part way down the 
directory tree, but fail if I start further up.

I have reindexed the disk by putting it in Spotlight's "don't search" 
list and then removing it. No change.

I have checked read and write permissions and changed them to "read and 
write" on the entire disk. No change.

I set the disk permissions to "Ignore ownership". No change.

Any suggestions or insights to share?

Isaac

[toc] | [next] | [standalone]

#68926 — Re: Problems with Spotlight comments -- Solved

In article <isw-6C5E7E.21510922012015@news-roam.garlic.com>,
 isw <isw@witzend.com> wrote:

> I'm currently trying to deal with a whole lot of files (>20k) which have 
> been tagged using Spotlight comments. The files in question are not on 
> my system disk, but on another local disk which is mounted at all times; 
> I don't know if that matters.
> 
> Some of the files do not show up using Spotlight to search on comments, 
> despite the fact that I can see the comments if I do a "get info" on the 
> files.
> 
> Some of the files show up when I execute a search part way down the 
> directory tree, but fail if I start further up.
> 
> I have reindexed the disk by putting it in Spotlight's "don't search" 
> list and then removing it. No change.
> 
> I have checked read and write permissions and changed them to "read and 
> write" on the entire disk. No change.
> 
> I set the disk permissions to "Ignore ownership". No change.
> 
> Any suggestions or insights to share?

I got no responses to my query, but finally managed to figure out (I 
think) what's going on. I thought I'd post what I learned here, just to 
finish up the thread and put things "on record".

This may not be authoritative, but it's what I have gathered over the 
past few days:

In older versions of OS X, Spotlight comments associated with a file 
were stored, not in the file itself, but in the .DS_Store file of the 
folder containing the file. (Open the .DS_Store file in a text editor to 
see them).

Somewhere around 10.4 or .5, the comments started being stored in the 
extended attributes of the file. This solved a problem with the previous 
method, where it was all too easy to move a file and lose the comments. 
(Run <xattr -l> on the file to see a comment, if there is one).

Presumably, after the change, apps that write Spotlight comments were 
modified to put the comments in *both* places, to assure backwards 
compatibility (??).

In an environment where files have been created and tagged and juggled 
around for a long time -- regularly adding to a growing collection, say 
-- there could be a situation where some files' comments were "inside" 
(in the file's extended attributes), some were in the .DS_Store of the 
containing folder, and some files had the comments stored in both 
places. 

Now here's where the problem comes in:

Near as I can tell, when a Spotlight search is done looking for 
comments, the file's attributes are checked, but the .DS_Store *is not* 
(or maybe it is checked but if it's empty, it's silently ignored).

Then, when Finder (I suppose???) presents the list of found files, 
evidently it reads the .DS_Store file and *not* the attributes, to 
decide what to display.

So you can have a situation where you do a search for files with some 
particular value in the Spotlight comments, and in the resulting list, 
some of the files' "comments" entry is blank or incorrect, even though 
the file met the conditions for inclusion in the list (i.e. the comment 
was there -- somewhere).

FWIW, it seems that doing a "Get Info" on a file delivers any comment 
stored in the .DS_Store file, ignoring what might be in the file's 
extended attribute data.

Using a current version of a tool (such as Automator) to re-enter the 
comment will result in it being written in both places, which solves the 
problem.

My terminal and script skills are extremely limited, so I repaired the 
problem files manually, but I expect that someone with better scripting 
skills could automate the whole process.

Isaac

[toc] | [prev] | [next] | [standalone]

#68935 — Re: Problems with Spotlight comments -- Solved

On 2015-01-25, isw <isw@witzend.com> wrote:
>
> In older versions of OS X, Spotlight comments associated with a file 
> were stored, not in the file itself, but in the .DS_Store file of the 
> folder containing the file. (Open the .DS_Store file in a text editor to 
> see them).
>
> Somewhere around 10.4 or .5, the comments started being stored in the 
> extended attributes of the file. This solved a problem with the previous 
> method, where it was all too easy to move a file and lose the comments. 
> (Run <xattr -l> on the file to see a comment, if there is one).
>
> Presumably, after the change, apps that write Spotlight comments were 
> modified to put the comments in *both* places, to assure backwards 
> compatibility (??).

*sigh* Whoever came up with the complete mess that is DS_Store should be
locked in a dungeon until it is vanquished from Mac OS X for good, IMO. 

Thanks for the follow-up post.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#68956 — Re: Problems with Spotlight comments -- Solved

>> In older versions of OS X, Spotlight comments associated with a file
>> were stored, not in the file itself, but in the .DS_Store file of the
>> folder containing the file. (Open the .DS_Store file in a text editor to
>> see them).
>>
>> Somewhere around 10.4 or .5, the comments started being stored in the
>> extended attributes of the file. This solved a problem with the previous
>> method, where it was all too easy to move a file and lose the comments.
>> (Run <xattr -l> on the file to see a comment, if there is one).
>>
>> Presumably, after the change, apps that write Spotlight comments were
>> modified to put the comments in *both* places, to assure backwards
>> compatibility (??).
>
> *sigh* Whoever came up with the complete mess that is DS_Store should be
> locked in a dungeon until it is vanquished from Mac OS X for good, IMO.

Ditto. Annoying files on non-Apple places too.
-- 
"Ants. There's a size for every picnic, a colour for every occasion, and 
a bite to let you know that they are there. Apart from the bite, that 
could describe a Basenji pretty well." --Len Reddie
    /\___/\         Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site)
   / /\ /\ \                Ant's Quality Foraged Links: http://aqfl.net
  | |o   o| |
     \ _ /        If crediting, then use Ant nickname and AQFL URL/link.
      ( )         If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.

[toc] | [prev] | [next] | [standalone]

#68960 — Re: Problems with Spotlight comments -- Solved

In article <k9KdncHPu8M_0VjJnZ2dnUU7-L2dnZ2d@earthlink.com>, Ant
<ant@zimage.comANT> wrote:

> > *sigh* Whoever came up with the complete mess that is DS_Store should be
> > locked in a dungeon until it is vanquished from Mac OS X for good, IMO.
> 
> Ditto. Annoying files on non-Apple places too.

that can be disabled.

[toc] | [prev] | [next] | [standalone]

#68961 — Re: Problems with Spotlight comments -- Solved

On 2015-01-25, nospam <nospam@nospam.invalid> wrote:
> In article <k9KdncHPu8M_0VjJnZ2dnUU7-L2dnZ2d@earthlink.com>, Ant
><ant@zimage.comANT> wrote:
>
>> > *sigh* Whoever came up with the complete mess that is DS_Store should be
>> > locked in a dungeon until it is vanquished from Mac OS X for good, IMO.
>> 
>> Ditto. Annoying files on non-Apple places too.
>
> that can be disabled.

True, you can prevent a Mac from creating .DS_Store files on network
volumes by setting the following hidden preference:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Note, however, that this must be done on each and every Mac that will
access that network volume to be effective. 

There are other files that Mac OS X creates that may confound users of
other operating systems, such as "_MACOSX" folders in ZIP archives.
These are created to hold information that is normally stored in the
resource fork of the HFS file system. You can omit these from ZIP
archives by supplying the -X command-line switch when creating the ZIP
archive on the command line, if desired. You can also strip the resource
forks of any files you add to the ZIP archive to ensure no such folders
are created. But the folder and its contents don't cause problems on
other operating systems, and can be safely ignored.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#68963 — Re: Problems with Spotlight comments -- Solved

On 1/25/2015 1:00 PM, Jolly Roger wrote:

>>>> *sigh* Whoever came up with the complete mess that is DS_Store should be
>>>> locked in a dungeon until it is vanquished from Mac OS X for good, IMO.
>>>
>>> Ditto. Annoying files on non-Apple places too.
>>
>> that can be disabled.
>
> True, you can prevent a Mac from creating .DS_Store files on network
> volumes by setting the following hidden preference:
>
> defaults write com.apple.desktopservices DSDontWriteNetworkStores true
>
> Note, however, that this must be done on each and every Mac that will
> access that network volume to be effective.
>
> There are other files that Mac OS X creates that may confound users of
> other operating systems, such as "_MACOSX" folders in ZIP archives.
> These are created to hold information that is normally stored in the
> resource fork of the HFS file system. You can omit these from ZIP
> archives by supplying the -X command-line switch when creating the ZIP
> archive on the command line, if desired. You can also strip the resource
> forks of any files you add to the ZIP archive to ensure no such folders
> are created. But the folder and its contents don't cause problems on
> other operating systems, and can be safely ignored.

Is there a side effect of diasbling them for Macs?
-- 
"When the ants unite their mouths, they can carry an elephant." 
--Mossian Proverb
    /\___/\         Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site)
   / /\ /\ \                Ant's Quality Foraged Links: http://aqfl.net
  | |o   o| |
     \ _ /        If crediting, then use Ant nickname and AQFL URL/link.
      ( )         If e-mailing, then axe ANT from its address if needed.
A song (i/wa)s playing on this computer: Johann Sebastian Bach - Toccata 
and Fugue in D minor (Vanessa-Mae Remix)

[toc] | [prev] | [next] | [standalone]

#68964 — Re: Problems with Spotlight comments -- Solved

On 2015-01-25, Ant <ant@zimage.comANT> wrote:
> On 1/25/2015 1:00 PM, Jolly Roger wrote:
>
>>>>> *sigh* Whoever came up with the complete mess that is DS_Store should be
>>>>> locked in a dungeon until it is vanquished from Mac OS X for good, IMO.
>>>>
>>>> Ditto. Annoying files on non-Apple places too.
>>>
>>> that can be disabled.
>>
>> True, you can prevent a Mac from creating .DS_Store files on network
>> volumes by setting the following hidden preference:
>>
>> defaults write com.apple.desktopservices DSDontWriteNetworkStores true
>>
>> Note, however, that this must be done on each and every Mac that will
>> access that network volume to be effective.
>>
>> There are other files that Mac OS X creates that may confound users of
>> other operating systems, such as "_MACOSX" folders in ZIP archives.
>> These are created to hold information that is normally stored in the
>> resource fork of the HFS file system. You can omit these from ZIP
>> archives by supplying the -X command-line switch when creating the ZIP
>> archive on the command line, if desired. You can also strip the resource
>> forks of any files you add to the ZIP archive to ensure no such folders
>> are created. But the folder and its contents don't cause problems on
>> other operating systems, and can be safely ignored.
>
> Is there a side effect of diasbling them for Macs?

_MACOSX folders? Yes. Whatever data was stored in them is lost.
Depending on the file types within the ZIP archive, that can cause the
files to be missing important data. So it's best only to remove this
information for files that you never plan to edit or use on a Mac again.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.mac.system

csiph-web