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

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

Spotlight finds things that aren't there

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

Contents

  Spotlight finds things that aren't there isw <isw@witzend.com> - 2015-05-28 10:19 -0700
    Re: Spotlight finds things that aren't there Alan Browne <alan.browne@freelunchvideotron.ca> - 2015-05-28 13:38 -0400
      Re: Spotlight finds things that aren't there D Finnigan <dog_cow@macgui.com> - 2015-05-28 17:46 +0000
        Re: Spotlight finds things that aren't there Alan Browne <alan.browne@freelunchvideotron.ca> - 2015-05-28 14:05 -0400
    Re: Spotlight finds things that aren't there D Finnigan <dog_cow@macgui.com> - 2015-05-28 17:37 +0000
    Re: Spotlight finds things that aren't there JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-05-28 13:43 -0400
      Re: Spotlight finds things that aren't there isw <isw@witzend.com> - 2015-05-28 21:30 -0700
        Re: Spotlight finds things that aren't there Alan Baker <email@domain.com> - 2015-06-02 07:56 -0700
          Re: Spotlight finds things that aren't there isw <isw@witzend.com> - 2015-06-02 10:52 -0700
            Re: Spotlight finds things that aren't there Alan Baker <email@domain.com> - 2015-06-02 13:38 -0700
              Re: Spotlight finds things that aren't there isw <isw@witzend.com> - 2015-06-02 21:36 -0700
                Re: Spotlight finds things that aren't there JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-06-03 13:17 -0400
                  Re: Spotlight finds things that aren't there Alan Baker <email@domain.com> - 2015-06-03 10:28 -0700
                  Re: Spotlight finds things that aren't there isw <isw@witzend.com> - 2015-06-03 21:49 -0700
    Re: Spotlight finds things that aren't there Barry Margolin <barmar@alum.mit.edu> - 2015-05-28 16:14 -0400
      Re: Spotlight finds things that aren't there JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-05-28 16:25 -0400
      Re: Spotlight finds things that aren't there isw <isw@witzend.com> - 2015-05-28 21:27 -0700
        Re: Spotlight finds things that aren't there -- solution, sort of isw <isw@witzend.com> - 2015-05-30 21:26 -0700
          Re: Spotlight finds things that aren't there -- solution, sort of JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-05-31 03:12 -0400
            Re: Spotlight finds things that aren't there -- solution, sort of isw <isw@witzend.com> - 2015-05-31 20:52 -0700
        Re: Spotlight finds things that aren't there -- Follow-on question isw <isw@witzend.com> - 2015-05-30 21:38 -0700
          Re: Spotlight finds things that aren't there -- Follow-on question Jim Gibson <JimSGibson@gmail.com> - 2015-05-31 22:25 -0700
            Re: Spotlight finds things that aren't there -- Follow-on question isw <isw@witzend.com> - 2015-06-01 09:34 -0700
              Re: Spotlight finds things that aren't there -- Follow-on question Martin Frost me at invalid stanford daht edu <nospam@stanford.edu.invalid> - 2015-06-01 19:08 -0700

Page 1 of 2  [1] 2  Next page →

#75998 — Spotlight finds things that aren't there

 For some time, I was mildly annoyed because every time I did a 
Spotlight search for a text string in a file, a bunch of JPG files 
showed up in the results. I just assumed that the nearly random content 
of a JPG (and I have a lot of them) sometimes had a string of bytes that 
matched the search criteria.

Yesterday I was doing a lot of searching, and I happened to notice that, 
no matter what string I was searching for, the same JPGs always showed 
up in the result and no others did. Odd.

So I rebuilt the Spotlight database (drag all the disks into the 
"Privacy" list, then remove them).

Most of the JPGs disappeared from the results, but two remain. I even 
rebuilt the database for their containing folder again. Still there.

To recap: no matter what search phrase I use, these two JPGs always show 
up in the result list.

What's going on?

Isaac

[toc] | [next] | [standalone]

#75999

On 2015-05-28 13:19, isw wrote:
>   For some time, I was mildly annoyed because every time I did a
> Spotlight search for a text string in a file, a bunch of JPG files
> showed up in the results. I just assumed that the nearly random content
> of a JPG (and I have a lot of them) sometimes had a string of bytes that
> matched the search criteria.
>
> Yesterday I was doing a lot of searching, and I happened to notice that,
> no matter what string I was searching for, the same JPGs always showed
> up in the result and no others did. Odd.
>
> So I rebuilt the Spotlight database (drag all the disks into the
> "Privacy" list, then remove them).
>
> Most of the JPGs disappeared from the results, but two remain. I even
> rebuilt the database for their containing folder again. Still there.
>
> To recap: no matter what search phrase I use, these two JPGs always show
> up in the result list.
>
> What's going on?


Hard to tell.  There are a variety of files I access (or apps that I 
run) using Spotlight and it's always worked well.  But recently it 
presented strange results over the course of a few days before getting 
back to normal.  I did not force a rebuild.


But JPG's (and I've got well over 100,000 on here) never show up unless 
the search is part of the file name.

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

#76002

Alan Browne wrote:
> 
> But JPG's (and I've got well over 100,000 on here) never show up unless 
> the search is part of the file name.
>

I don't think that's always true. Try searching for some of the meta
data/EXIF tags in a picture.

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

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

#76003

On 2015-05-28 13:46, D Finnigan wrote:
> Alan Browne wrote:
>>
>> But JPG's (and I've got well over 100,000 on here) never show up unless
>> the search is part of the file name.
>>
>
> I don't think that's always true. Try searching for some of the meta
> data/EXIF tags in a picture.

True enough.  OTOH, in my case at least, most of my JPG's are scans from 
film and I did not tag them with much text data.  Those taken with 
digital cameras will often have date/time/location (as lat/long) but 
little else.

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

#76000

isw wrote:
> For some time, I was mildly annoyed because every time I did a 
> Spotlight search for a text string in a file, a bunch of JPG files 
> showed up in the results. I just assumed that the nearly random content 
> of a JPG (and I have a lot of them) sometimes had a string of bytes that 
> matched the search criteria.

Well there's EXIF tags and data too, like author and keywords and so on.



-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

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

#76001

On 15-05-28 13:19, isw wrote:
>  For some time, I was mildly annoyed because every time I did a 
> Spotlight search for a text string in a file, a bunch of JPG files 
> showed up in the results. 


Just a theory: could your jpg files contain exif data (comments) that
contain the searched strings ?

Or perhaps those .jpgs are highly embarassing and the OS knows it and
wants to embarass you by always presenting them to you and anyone who
might be looking over your shoulders :-)

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

#76014

In article <556753ac$0$46925$c3e8da3$aae71a0a@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-05-28 13:19, isw wrote:
> >  For some time, I was mildly annoyed because every time I did a 
> > Spotlight search for a text string in a file, a bunch of JPG files 
> > showed up in the results. 
> 
> 
> Just a theory: could your jpg files contain exif data (comments) that
> contain the searched strings ?

No. I looked.

> Or perhaps those .jpgs are highly embarassing and the OS knows it and
> wants to embarass you by always presenting them to you and anyone who
> might be looking over your shoulders :-)

One was a photo of an Altair 8800 board I sold on eBay; the other was a 
photo of a paper tape containing a Cromemco Z-80 monitor routine.

Should I be embarrassed?

Isaac

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

#76053

On 2015-05-29 04:30:28 +0000, isw said:

> In article <556753ac$0$46925$c3e8da3$aae71a0a@news.astraweb.com>,
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
>> On 15-05-28 13:19, isw wrote:
>>> For some time, I was mildly annoyed because every time I did a
>>> Spotlight search for a text string in a file, a bunch of JPG files
>>> showed up in the results.
>> 
>> 
>> Just a theory: could your jpg files contain exif data (comments) that
>> contain the searched strings ?
> 
> No. I looked.
> 
>> Or perhaps those .jpgs are highly embarassing and the OS knows it and
>> wants to embarass you by always presenting them to you and anyone who
>> might be looking over your shoulders :-)
> 
> One was a photo of an Altair 8800 board I sold on eBay; the other was a
> photo of a paper tape containing a Cromemco Z-80 monitor routine.
> 
> Should I be embarrassed?
> 
> Isaac

Can you do an "mdls" command on the file using Terminal and then pipe 
the results to grep them against the string that produce it as a result?

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

#76057

In article <mkkg7r$b00$1@news.datemas.de>,
 Alan Baker <email@domain.com> wrote:

> On 2015-05-29 04:30:28 +0000, isw said:
> 
> > In article <556753ac$0$46925$c3e8da3$aae71a0a@news.astraweb.com>,
> >  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> > 
> >> On 15-05-28 13:19, isw wrote:
> >>> For some time, I was mildly annoyed because every time I did a
> >>> Spotlight search for a text string in a file, a bunch of JPG files
> >>> showed up in the results.
> >> 
> >> 
> >> Just a theory: could your jpg files contain exif data (comments) that
> >> contain the searched strings ?
> > 
> > No. I looked.
> > 
> >> Or perhaps those .jpgs are highly embarassing and the OS knows it and
> >> wants to embarass you by always presenting them to you and anyone who
> >> might be looking over your shoulders :-)
> > 
> > One was a photo of an Altair 8800 board I sold on eBay; the other was a
> > photo of a paper tape containing a Cromemco Z-80 monitor routine.
> > 
> > Should I be embarrassed?
> > 
> > Isaac
> 
> Can you do an "mdls" command on the file using Terminal and then pipe 
> the results to grep them against the string that produce it as a result?

I could, but I don't think it would prove anything -- it wasn't one 
string, it was *every* string I searched with, that delivered the same 
set of JPGs in the result. Something else was going on.

As I said in another post, recoding the images (I made very minor 
adjustments in Preview, and then did a "Save as" seems to have solved 
the problem.

Isaac

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

#76060

On 2015-06-02 17:52:11 +0000, isw said:

> In article <mkkg7r$b00$1@news.datemas.de>,
>  Alan Baker <email@domain.com> wrote:
> 
>> On 2015-05-29 04:30:28 +0000, isw said:
>> 
>>> In article <556753ac$0$46925$c3e8da3$aae71a0a@news.astraweb.com>,
>>> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>> 
>>>> On 15-05-28 13:19, isw wrote:
>>>>> For some time, I was mildly annoyed because every time I did a
>>>>> Spotlight search for a text string in a file, a bunch of JPG files
>>>>> showed up in the results.
>>>> 
>>>> 
>>>> Just a theory: could your jpg files contain exif data (comments) that
>>>> contain the searched strings ?
>>> 
>>> No. I looked.
>>> 
>>>> Or perhaps those .jpgs are highly embarassing and the OS knows it and
>>>> wants to embarass you by always presenting them to you and anyone who
>>>> might be looking over your shoulders :-)
>>> 
>>> One was a photo of an Altair 8800 board I sold on eBay; the other was a
>>> photo of a paper tape containing a Cromemco Z-80 monitor routine.
>>> 
>>> Should I be embarrassed?
>>> 
>>> Isaac
>> 
>> Can you do an "mdls" command on the file using Terminal and then pipe
>> the results to grep them against the string that produce it as a result?
> 
> I could, but I don't think it would prove anything -- it wasn't one
> string, it was *every* string I searched with, that delivered the same
> set of JPGs in the result. Something else was going on.

"Prove anything"? Probably not.

Show some things that might be of interest? Well, you won't know that 
until you try:

In the Terminal:

mdls <fullPathnameOfFile> | grep <stringYouTypedInSpotlightSearchBox>

> 
> As I said in another post, recoding the images (I made very minor
> adjustments in Preview, and then did a "Save as" seems to have solved
> the problem.
> 
> Isaac

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

#76064

In article <mkl485$mb8$1@news.datemas.de>,
 Alan Baker <email@domain.com> wrote:

> On 2015-06-02 17:52:11 +0000, isw said:
> 
> > In article <mkkg7r$b00$1@news.datemas.de>,
> >  Alan Baker <email@domain.com> wrote:
> > 
> >> On 2015-05-29 04:30:28 +0000, isw said:
> >> 
> >>> In article <556753ac$0$46925$c3e8da3$aae71a0a@news.astraweb.com>,
> >>> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> >>> 
> >>>> On 15-05-28 13:19, isw wrote:
> >>>>> For some time, I was mildly annoyed because every time I did a
> >>>>> Spotlight search for a text string in a file, a bunch of JPG files
> >>>>> showed up in the results.
> >>>> 
> >>>> 
> >>>> Just a theory: could your jpg files contain exif data (comments) that
> >>>> contain the searched strings ?
> >>> 
> >>> No. I looked.
> >>> 
> >>>> Or perhaps those .jpgs are highly embarassing and the OS knows it and
> >>>> wants to embarass you by always presenting them to you and anyone who
> >>>> might be looking over your shoulders :-)
> >>> 
> >>> One was a photo of an Altair 8800 board I sold on eBay; the other was a
> >>> photo of a paper tape containing a Cromemco Z-80 monitor routine.
> >>> 
> >>> Should I be embarrassed?
> >>> 
> >>> Isaac
> >> 
> >> Can you do an "mdls" command on the file using Terminal and then pipe
> >> the results to grep them against the string that produce it as a result?
> > 
> > I could, but I don't think it would prove anything -- it wasn't one
> > string, it was *every* string I searched with, that delivered the same
> > set of JPGs in the result. Something else was going on.
> 
> "Prove anything"? Probably not.
> 
> Show some things that might be of interest? Well, you won't know that 
> until you try:
> 
> In the Terminal:
> 
> mdls <fullPathnameOfFile> | grep <stringYouTypedInSpotlightSearchBox>

I pulled one of the offending files from a backup to try this. Found 
nothing. Early in the investigation, I opened a few of the offending 
JPGs with TextWrangler (as text) and did some poking around/searching; 
found nothing then either.

Not surprising, because those files would have to be awfully big to hold 
a copy of *every search phrase it's possible to enter*. I'm convinced 
that something the old camera did (wrong) when encoding the JPGs caused 
some sort of a "wild card" that would match absolutely anything. I think 
that's why re-encoding the files fixed things.

Isaac

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

#76068

On 15-06-03 00:36, isw wrote:

> a copy of *every search phrase it's possible to enter*. I'm convinced 
> that something the old camera did (wrong) when encoding the JPGs caused 
> some sort of a "wild card" that would match absolutely anything. I think 
> that's why re-encoding the files fixed things.


More likely: the "save as" created a new file which triggers spotlight
to re-index the file, at which point, it is removed from all the
keywords that the old version of file had (by mistake).

I have also found some image files appearing for no real reason in
spotlight searches, but always ignored it. Probably a big in the software.

Question:

If a file is allocated as 200k, but only 20k is actually written to it,
would Spotlight's magical powers have access to the unused 180k beyond
the end of file ? If those unused blocks contained a text with lots of
keywords, that might explain how a image file would get intexed to match
so many keywords.


(this has to do whether disk blocks are erased upon file deletion, erase
upon file allocation, or whether high water marking is used to prevent
normal application from reading past the end of file. (And I suspect
Spotlight may use lower level access to data to make it more efficient
and might be granted access beyond end of file. Just a theory.

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

#76069

On 2015-06-03 17:17:18 +0000, JF Mezei said:

> On 15-06-03 00:36, isw wrote:
> 
>> a copy of *every search phrase it's possible to enter*. I'm convinced
>> that something the old camera did (wrong) when encoding the JPGs caused
>> some sort of a "wild card" that would match absolutely anything. I think
>> that's why re-encoding the files fixed things.
> 
> 
> More likely: the "save as" created a new file which triggers spotlight
> to re-index the file, at which point, it is removed from all the
> keywords that the old version of file had (by mistake).
> 
> I have also found some image files appearing for no real reason in
> spotlight searches, but always ignored it. Probably a big in the software.
> 
> Question:
> 
> If a file is allocated as 200k, but only 20k is actually written to it,
> would Spotlight's magical powers have access to the unused 180k beyond
> the end of file ? If those unused blocks contained a text with lots of
> keywords, that might explain how a image file would get intexed to match
> so many keywords.
> 
> 
> (this has to do whether disk blocks are erased upon file deletion, erase
> upon file allocation, or whether high water marking is used to prevent
> normal application from reading past the end of file. (And I suspect
> Spotlight may use lower level access to data to make it more efficient
> and might be granted access beyond end of file. Just a theory.

Doubtful...

Spotlights underlying metadata importer is informed by fseventsd that a 
file has been created or changed and the importer then updates the 
Spotlight indexes accordingly. As such, it is operating at the file 
level, not the block level.

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

#76094

In article <556f369f$0$20019$c3e8da3$1cbc7475@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-06-03 00:36, isw wrote:
> 
> > a copy of *every search phrase it's possible to enter*. I'm convinced 
> > that something the old camera did (wrong) when encoding the JPGs caused 
> > some sort of a "wild card" that would match absolutely anything. I think 
> > that's why re-encoding the files fixed things.
> 
> 
> More likely: the "save as" created a new file which triggers spotlight
> to re-index the file, at which point, it is removed from all the
> keywords that the old version of file had (by mistake).

Creating a copy with a different name immediately causes the "new" file 
to show up in Spotlight. Deleting the original and renaming the copy has 
no effect. This is true even when the copy is made by GIMP but without 
having GIMP make any edits to the file.

> I have also found some image files appearing for no real reason in
> spotlight searches, but always ignored it. Probably a big in the software.

My suspicion is that it's a bug in Spotlight *and* an error of some sort 
in the image files.

> Question:
> 
> If a file is allocated as 200k, but only 20k is actually written to it,
> would Spotlight's magical powers have access to the unused 180k beyond
> the end of file ? If those unused blocks contained a text with lots of
> keywords, that might explain how a image file would get intexed to match
> so many keywords.

But doesn't explain why copying the file (even to a different folder) or 
restoring the file from Time Machine (overwriting the original) fails to 
eliminate the error.

> (this has to do whether disk blocks are erased upon file deletion, erase
> upon file allocation, or whether high water marking is used to prevent
> normal application from reading past the end of file. (And I suspect
> Spotlight may use lower level access to data to make it more efficient
> and might be granted access beyond end of file. Just a theory.

As I said before, my best guess is that there is some "bug" in the old 
camera's JPG encoding routines, which puts something in the file that 
Spotlight sees as a wildcard. Remember, I could find *no* search term 
that would not "find" these files. A few hundred k doesn't even get 
close to a universal library of search terms.

Anyhow, it was only about 50 files, so I ran them all through Preview, 
applying an innocuous edit, and the problem went away.

Isaac

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

#76005

In article <isw-5CE33E.10194928052015@news-roam.garlic.com>,
 isw <isw@witzend.com> wrote:

> To recap: no matter what search phrase I use, these two JPGs always show 
> up in the result list.

Even if you just mash the keyboard so you get a randomish search string?

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

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

#76007

I have about 400 .tif files with the word "New Zealand" in the comments.

spotlight found 5 of them. (file names such as scan0291.tif and
19920327.tif, so the file name itself is not indicative of it, and the
folders are /slides and /slides/zpre-file  so again, no indication it is
new zealand)

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

#76013

In article <barmar-2DF57E.16143728052015@88-209-239-213.giganet.hu>,
 Barry Margolin <barmar@alum.mit.edu> wrote:

> In article <isw-5CE33E.10194928052015@news-roam.garlic.com>,
>  isw <isw@witzend.com> wrote:
> 
> > To recap: no matter what search phrase I use, these two JPGs always show 
> > up in the result list.
> 
> Even if you just mash the keyboard so you get a randomish search string?

Yup. "arglebargle", "zzzxzzz", and every legitimate search word I tried.

Isaac

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

#76028 — Re: Spotlight finds things that aren't there -- solution, sort of

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

> In article <barmar-2DF57E.16143728052015@88-209-239-213.giganet.hu>,
>  Barry Margolin <barmar@alum.mit.edu> wrote:
> 
> > In article <isw-5CE33E.10194928052015@news-roam.garlic.com>,
> >  isw <isw@witzend.com> wrote:
> > 
> > > To recap: no matter what search phrase I use, these two JPGs always show 
> > > up in the result list.

I misspoke; there were actually about 50 JPGs that always showed up. 
when I checked things after the Spotlight database rebuild, I only got 
two, but unknown to me Spotlight was still working on the rebuild. When 
it was done, the same 50 files were in every search I did. The problem 
(at least this particular one) was not a corrupt database.

Turns out that all the problem files were created by one, old, 
not-a-name-brand digital camera.

I did a fair amount of poking around to see if I could understand 
exactly what was wrong with the files, but finally gave up and went for 
the practical solution.

Doing a finder duplicate of the offending file does not work.

Opening the file in Preview and saving over the original does not work.

Opening the file in Preview, doing a slight edit and saving over the 
original sometimes works.

Opening the file and doing a Save As *to the same name* (overwriting the 
original file) sometimes works.

Opening the file with Preview and making an edit *however slight* and 
then doing a Save As always works.

("Works" means the file no longer shows up in arbitrary Spotlight 
searches).

So my best guess is that something in the way that old camera encoded 
JPGs gives Spotlight a case of indigestion (which is, IMO, a bug; why is 
Spotlight trying to index the contents of encoded images?).

The Open-Save routines that failed were likely not re-encoding the 
image, but any sort of manipulation that causes Preview to re-encode it 
gets rid of whatever the problem is.

Isaac

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

#76030 — Re: Spotlight finds things that aren't there -- solution, sort of

On 15-05-31 00:26, isw wrote:

> I did a fair amount of poking around to see if I could understand 
> exactly what was wrong with the files, but finally gave up and went for 
> the practical solution.

Look for a took called "exiftool"  it comes from queens university in
Kingston Ontario Canada. It is a command line tool.

basically exiftool -all <filename>  will list all attributes in the
file. You may see some keywords there that Spotlight would capture.

Another thing to consider: if those filea are part of iPhoto, iPhoto has
its own database where various info about an image is stored, including
comments, keywords, location. (may or may not be copies of what is in
the exifdata, g=but I know that comments added in iPhoto do not get put
into the image file as exifdata, it stays as iPhoto database data.

Spotlight may be smart enough to index an image file based on iPhoto
database data.

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

#76035 — Re: Spotlight finds things that aren't there -- solution, sort of

In article <556ab45e$0$64259$c3e8da3$b280bf18@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-05-31 00:26, isw wrote:
> 
> > I did a fair amount of poking around to see if I could understand 
> > exactly what was wrong with the files, but finally gave up and went for 
> > the practical solution.
> 
> Look for a took called "exiftool"  it comes from queens university in
> Kingston Ontario Canada. It is a command line tool.
> 
> basically exiftool -all <filename>  will list all attributes in the
> file. You may see some keywords there that Spotlight would capture.

I looked at the EXIF stuff; that's very unlikely to be where the problem 
is. There is no obvious difference between the EXIF of a file that is 
always found and one that is not.

> Another thing to consider: if those filea are part of iPhoto, iPhoto has
> its own database where various info about an image is stored, including
> comments, keywords, location. (may or may not be copies of what is in
> the exifdata, g=but I know that comments added in iPhoto do not get put
> into the image file as exifdata, it stays as iPhoto database data.

My photos are accessed by iPhoto, but are stored externally, in a 
standard folder heirarchy. (I'm planning for the day when my kids want 
to view the images, but there is no iPhoto around.)

Isaac

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web