Metadata into book, again?

[enonod]

I only persist with my questions because so many answers/postings in this forum contain phrases such as "I believe", "I presume", "probably"; not because I wish to fire argument.

@DoctorOhh: Thank you for your response and effort.

True, Unless you do a conversion or go out of your way using Polish or Modify Epub plugin the metadata in books are updated upon export from the calibre library. It is explained well in post 3.

I confess that I missed "...but not in the base format" in post #3.

Are the books moved or is the folder simply renamed? I'm guessing the folders are simply renamed by the OS. If that OS process requires a "move" it is still a single entry in the allocation table not actually moving a large file. Either way these are a blink compared to expanding a book writing to it and re-compressing it.

I refer to my comments to BetterRed below regarding multiple books, one author and the various types of file system.

Keep in mind the old opf files have nothing to do with calibre storing metadata for books. These files are used to restore the database in case of database corruption.

I was obviously mistaken in thinking they were 'like' sidecar files that carried what was 'not' in the book and that it was part of the ePub standard that every book has one.

eBooks are obviously a very complex subject.

@BetterRed: Thank you for your response and time obviously taken.
I am not expecting to turn this into a controversy but I do not fully agree with you although your (b) is an interesting point.

i.e they want the RAW kept in the same state as it left the camera.

I accept regarding RAW but it is now becoming the norm, however most photo's kept in database are not RAW but JPG or otherwise and there is no 'contamination'. It is standard practice, especially with journalists and the like and in fact it is necessary in order to copyright, watermark and provide the receiving potential buyer with keywords describing the content. Sidecar files are now tending to be used only where the original cannot be written to and until recently this applied to all RAW files and for a few it is still true.

With advanced file systems, eg NFS, HFS+, NTFS etc, when a folder (directory) is renamed (or moved within a device) it all happens within the file system index/directory/master file table structures. The contents of the folder are not moved, so a folder containing 200GB of data can be renamed just as fast as folder with 2KB can be. This is not true of primitive file systems such as FAT or BDOS.

Can you confirm categorically that an author folder containing sub-folders for each book, does not result in moving a single book or its folder if the author name is changed for that book only (such that the book must then become a sub folder of a different author folder)? It does not require renaming the title is the same.
I think you are suggesting that manipulation of File Allocation Tables in Windows (whether the Calibre owner is using FAT, FAT32, NTFS or whatever) is all that is required to have the folder appear elsewhere in a different hierarchy, which action is of course hidden from the user (who thinks the folder was physically copied and then the original deleted).

[theducks]

@enonod
please do not mix MP3 and photo file rules in here.

RAW in book usage means AS DELIVERED (good or bad formatting as long as it is rulebook VALID EPUB or other format), The original file.

It can be pure hash as long as it passes validation and the don't touch my book purists (some of them are authors) are happy.
Calibre is a (Library) Filing system FIRST (which is why you can store a book WITH DRM)

[BetterRed]

Originally Posted by enonod

Can you confirm categorically that an author folder containing sub-folders for each book, does not result in moving a single book or its folder if the author name is changed for that book only (such that the book must then become a sub folder of a different author folder)? It does not require renaming the title is the same.
I think you are suggesting that manipulation of File Allocation Tables in Windows (whether the Calibre owner is using FAT, FAT32, NTFS or whatever) is all that is required to have the folder appear elsewhere in a different hierarchy, which action is of course hidden from the user (who thinks the folder was physically copied and then the original deleted).

I cannot be categorical about software I didn't write.

NTFS (an advanced file system) does not have a File Allocation Table, it has a Master File Table (MFT). Advanced file systems segregate the file system metadata (in NTFS into the MFT) from the content, so when a file (or folder) is renamed (or moved on the same device) only the the metadata is changed; the content (in NTFS speak its called the default data stream) stays where it is. Wikipedia has extensive entries on NTFS and other advanced file system.

I keep my libraries on a spinning disk formatted for NTFS. I recently renamed an author folder whose books were 40+ Gigabytes (HD scanned comics in CBZs and montage AVI's). It happened almost instantaneously, just as it would if I'd renamed the folder in Windows (File) Explorer.

Its so long since I used a FAT device for anything 'serious' that I'm not sure how fast it would handle something like that, but I suspect it would much slower than NTFS, NFS or HFS+ etc.

=================

This is not the place to discuss digital asset management software in any depth. But the DAM systems I've used to manage large (millions of images) archives only keep thumbnails in their database, the actual images in all their variations were stored in folders. Some of the packages that used Oracle/DB2 on big iron had the option of storing the images as database blobs, but we aren't in that territory here.

It's a bit of a waste of time comparing ebook management software with image and music management software, they come from different histories and contexts.

BR

[enonod]

@enonod
please do not mix MP3 and photo file rules in here.

@theducks:
Please note that my reference to RAW was a response to an earlier post which CLEARLY stated camera.

i.e they want the RAW kept in the same state as it left the camera.

Otherwise I am not sure what relevant point you are making.