Re: [gthumb-list] .Comment folder

[Paolo Bacchilega <paolo bacchilega libero it>]

Il 13/12/2012 14:17, Paolo Benvenuto ha scritto:
> Il giorno lun, 10/12/2012 alle 00.00 +0100, Paolo Bacchilega ha scritto:
> > Il 09/12/2012 18:10, Paolo Benvenuto ha scritto:
> > > Il giorno dom, 09/12/2012 alle 18.03 +0100, Paolo Benvenuto ha scritto:
> > > > Il giorno dom, 09/12/2012 alle 11.36 +0100, Paolo Bacchilega ha scritto:
> > > > > Il 21/11/2012 14:10, Paolo Benvenuto ha scritto:
> > > > > > I could reproduce the bug of the .Comments dir appeaaring (is it
> > > > > > https://bugzilla.gnome.org/show_bug.cgi?id=604720 ?):
> > > > >
> > > > > it not a bug, .comments directories are used to save image metadata.
> > > >
> > > > ok
> > > >
> > > > > > when I reselected
> > > > > > the "store metadata inside files if possible" I got the cpu and disk
> > > > > > hogging again. Deselecting the control stops the hogging.
> > > > > >
> > > > > > Actually the photo I attacched to previous message has a comment, but I
> > > > > > cannot delete it: if I do
> > > > > > - ctl-m
> > > > > > - select the whole comment and delete it
> > > > > > - save
> > > > > >
> > > > > > gthumb thinks it has deleted it, i.e. it doesn't report any error, but
> > > > > > the comment is still there.
> > > > >
> > > > > this bug should be fixed now in current development version.
> > > >
> > > > Actually now I can delete the comment.
> > >
> > > That's true, but the xml file in .comments is not deleted. I still have
> > > a file with content:
> > >
> > > ------------------
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <comment version="3.0">
> > >     <caption/>
> > >     <note/>
> > >     <place/>
> > >     <time value="2012:11:13 16:38:48"/>
> > >     <categories/>
> > > </comment>
> > > ------------------
> > >
> > > is it ok? I'd expect that, if I delete all the comments and other
> > > metadata which could be store in the file, this file is deleted too.
> >
> > this is the intended behaviour, it's useful to correctly synchronize the
> > .comment metadata and the embedded metadata.
>
> what is the intended behaviour when no metadata are present?
> - that an xml "void" file like that I posted above remain on disk?

this one

> - that the xml file is deleted?
>
> Actually gthumb work with the 1st behaviour, but I think the 2nd could
> be considered too.
>
>
> > > > What is not fixed is that if I select the "store metadata inside files
> > > > if possible" option gthumb (or something else) keeps creating and
> > > > deleting rapidly a file like .goutputstream-E7VHPW (every file which is
> > > > created has a different code after .goutputstream-) in the .comments
> > > > folder, and this hogs the cpu and the disk.
> >
> > there must be some special character in the embedded comment and causes
> > this error, it would be really useful if you could send me an image that
> > causes the problem
>
> I'm attacching the photo. In order to see the hogging you must activate
> the "store metadata inside files if possible" and double click on the
> photo.
>
> I doubt that "store metadata inside files if possible" explains the true
> behaviour of the option, I'd prefer "store metadata in a separate file
> if possible". Perhaps a radio button "store metadata: inside image/in a
> separate file" would be still better.

the option description is correct, the metadata is stored in two places: 
inside the file (if the image format allows to store metadata) and in 
the external xml file.

- Paolo