File Names (character lenght)

[guyanonymous]

I've noticed that the names of individual novel files as well as folder names are truncated.

If a book's title is long such as this:

12345678901234567890123456789012345678901234567890

the book's folder name may be:

123456789012345678901 (26326)

And while not shortened as much, the filename itself is also cut-off and may appear as:

12345678901234567890123456789012345 (26326).lit

___

What I'm wondering is a) what the limitations are for Author/Title Folder/Title Filename lenghts. I recognize they have to summatively stay under 256 characters in length (I believe that's the number) for most modern operating systems.

My concern around this is that some titles are identical except for the endings, which are not apparent in the saved files or folders they are in. In the case of a database crash (I do back mine up) or loss, the reimporting these files will be painful, as the filenames will not help you to distinguish each document's true identity. You'd have to go through them one by one.

If I'm missing a place to edit/control these limits, please direct me to it.

p.s., I'm on Vista 64bit.

[kovidgoyal]

The limit is hard coded as 255 chars *for the total path length*, you can't change it. And in any case changing it will cause you far more problems with long term stability.

[guyanonymous]

So what are the limits within the program (i.e., 50 characters for author name, 50 for book title folder name, etc)?

My only 'real' concern is that the file name itself contains the full title, but the current length has many of these file names being cut-off. For example I have a multi-file dictionary and the full title (which isn't that long) would include a Volume designator. Alas, the titles as stored on disk, are all the same except for the (#####) designator at the end, as the volume information is completely cut-off on all of them.

Any suggestions (other than abbreviating titles)? Even having some means to know what will be cut-off will be useful (knowing the numbers, a visual indicator such as colour change in the title input area/display of calibre).

Thanks for helping me figure this out.

[kovidgoyal]

there's no individual limit, an algorithm automatically shortens each component appropriately to keep the total length under 255.

*Do not* rely on metadata being stored in filenames. It's a really bad idea. Not only do file names have various limitations, they are not portable across different platforms.

If you're worried about losing metadata.db, back it up, that's what backups are for.

The only reason calibre puts metadata in file names at all is for user convenience when browsing the library folders. calibre will downnconvert all metadata to ascii, truncate it, remove various characters that are not supported on various filesystems and only then use the result as a file name

[guyanonymous]

While I can export full file names with a lot of flexibility, I do wish that storage names allowed for more flexibility. Alas, the 255 character length (thanks for the correction!) is frustrating, and one I encounter a fair bit organizing things.

I'm sure that the individual folder for each title is necessary, though I'm not 100% clear on why. Is it just because multiple versions of the same book can be stored there? Or are there other reasons as well?

I appreciate you're helping me understand it - even if nothing will change. By understanding the process, I'll figure out best how to live with it.

And just brainstorming, looking in one title's folder with three versions of the same book (I used to think you had to convert to epub before your final format for some reason).... if each file title has the (####) at the end AND the cover file did as well ( cover (####.jpg) ), would the title-folder be necessary at all?

[kovidgoyal]

If you remove the folders then you run into the limitation of windows that too many nodes in a single directory cause file access performance to slow down.

[guyanonymous]

What do you mean by nodes?

I've definitely noticed slowdowns in Windows because of the number of files/directories contained. I've never known, though, how many files/directories are required to trigger such a slowdown.

My impression was that the slowdown occurs only when reading the directory listing, not directly accessing files or moving files into the folder/out of the folder. Is this incorrect?

[kovidgoyal]

A node is an entry in a directory, i.e. either a file or a directory. I don't recall if the slowdown affects only listing or file access as well.

[guyanonymous]

Thanks for the edumation and explaining things to me!

I appreciate it. I'll figure out a way to survive