As there seems to be a lot of confusion about where and when ComicRack stores it's meta data, lets get it from the mouth of the horse :)
ComicRack always stores data as Xml snippets (either as part of the big library file) or as single small files into eComics (see below).
When adding or opening eComics and there is a secondary stream present for the file (only on NTFS), the xml data from this stream is loaded. If no stream is present and the eComic is an archive, it is opened and a ComicInfo.xml is searched.
If you change meta data, the data is stored to the Library and to the secondary NTFS stream (if the file is on NTFS and the write meta data to file option is turned on). The ComicInfo.xml file is changed/added for CBZ and CB7 eComics. For all other archive formats it is not touched.
ComicInfo.xml is also added to eComics when they are saved to an archive or file list format (Save as...) or converted (Convert to CBZ). Also only images not tagged as deleted are written.
Now you may wonder why this is done so complicated...
Using secondary streams on NTFS was the only plausible solution to store the info in a fast and format independed way. Also for a quick check ComicRack does not have to unpack the archives.
ComicRack supports various file formats (PDF, CBZ (ZIP), CBR(RAR), CB7(7z), TAR(CBT) and may add further formats in the future). Let's take a closer look at these different file formats:
- PDF: No archive at all, no place for ComicInfo.xml or any custom meta data.
- CBR: Rar format can not be written (proprietary)
- CBZ: ComicInfo.xml is updated
- CB7: ComicInfo.xml is updated
- CBT: "Streaming" archiv, no update because of performance issues.
- Future Formats: If they support fast replacement of the data file without unpacking the whole thing, comicrack will do it.
One of the implications for the whole process is also, that even if you only use ComicRacks file browser, you should still add all the files to the library. Because the library is the fastest way for ComicRack to get the data.
I hope everything is clear now.