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.okwhen 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? - 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.
- Paolo _______________________________________________ gthumb-list mailing list gthumb-list gnome org https://mail.gnome.org/mailman/listinfo/gthumb-list
-- Paolo Benvenuto http://it.cathopedia.org - Cathopedia, l'enciclopedia cattolica "on line"
Attachment:
photo which causes gthumb to hog cpu and disk.jpg
Description: JPEG image
