Calibre truncates long names on Win10 with long paths enabled.

[maximx86]

Hi,

I am new to Calibre and would appreciate someone to advise (or point into the right direction) why Calibre truncates long file names in Windows 10 with long paths enabled.

Before the long paths support was enabled Calibre would truncate all the metadata and the file names, but after the change it only truncates the file names. The metadata is intact.

Thanks

[kovidgoyal]

I dont know what you mean. metadata is written inside files, filenames have no bearing on it.

[realIK17]

@kovidgoyal

First of all, thank you for creating the app. It's very useful. However, I use moonreader to read ebooks so that my bookmarks can be synced across devices. I have several books with similar names except for a number at the end of the name. So the filenames for these books are all the same. moonreader syncs bookmarks based on filenames. So a few days after I started reading my second book, I realized that all my bookmarks from my first book were overwritten

I could use abbreviations for these books with similar long names, but it's a little inconvenient. Please consider addressing this issue. thanks

[phossler]

https://www.itprotoday.com/windows-1...ort-windows-10

In the past, the maximum supported file length was 260 characters (256 usable after the drive characters and termination character). In Windows 10, you can enable long file name support, which allows file names up to 32,767 characters (although you lose a few characters for mandatory characters that are part of the name).

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled = 1

So metadata like "Making Numbers Count: The Art and Science of Communicating Numbers" by Chip Heath & Karla Starr" gets stored on disc by Calibre as "Making Numbers Count_ The Art a - Chip Heath.epub"

I believe that's a limitation to work with other OSs

I use calibredb with the export option to copy files to a flat folder and name them based on metadata:

"Chip Heath & Karla Starr-Making Numbers Count_ The Art and Science of Communicating Numbers.epub"

and side load from the flat folder

[DNSB]

Originally Posted by phossler

So metadata like "Making Numbers Count: The Art and Science of Communicating Numbers" by Chip Heath & Karla Starr" gets stored on disc by Calibre as "Making Numbers Count_ The Art a - Chip Heath.epub"

I believe that's a limitation to work with other OSs

I have rarely seen the filename considered part of the metadata. Personally, I use a subtitle field which my Kobo ereaders are happy to display and a template to truncate the author portion of the filename to the first listed author to generate the filename when sending an ebook to my Kobo ereaders.

This does not affect the title or authors information stored in the metadata which is stored internal to the file and not as part of the filename.

[ownedbycats]

Originally Posted by phossler

I believe that's a limitation to work with other OSs

It is. If you copy a library folder from one OS to another, you won't run into any filepath issues from the length or illegal characters or the like.

In any case, you aren't meant to be mucking around in the library folder.

Think of it as a black box, one with a big warning label stating "NO USER SERVICEABLE PARTS INSIDE!" Or maybe a storage room with a locked door with a sign on it saying "PRIVATE - Calibre Only".

[gbm]

This sounds more like a moonreader problem than calibre.

bernie

Originally Posted by realIK17

@kovidgoyal

First of all, thank you for creating the app. It's very useful. However, I use moonreader to read ebooks so that my bookmarks can be synced across devices. I have several books with similar names except for a number at the end of the name. So the filenames for these books are all the same. moonreader syncs bookmarks based on filenames. So a few days after I started reading my second book, I realized that all my bookmarks from my first book were overwritten

I could use abbreviations for these books with similar long names, but it's a little inconvenient. Please consider addressing this issue. thanks

[BetterRed]

Originally Posted by phossler

[url]. . .
I use calibredb with the export option to copy files to a flat folder and name them based on metadata:

"Chip Heath & Karla Starr-Making Numbers Count_ The Art and Science of Communicating Numbers.epub"

and side load from the flat folder

Curious: Why calibredb export and not Save to Disk with a template?

BR

[phossler]

Originally Posted by BetterRed

Curious: Why calibredb export and not Save to Disk with a template?

BR

I have a VBS script that uses calibredb to

1. delete d:\ebooks\kfx folder
2. export using calibredb all kfx files to that folder as single level renaming using a template to add series if required so I can sideload to my KIndle

3. delete d:\ebooks\azw8 folder
4. copy d:\ebooks\kfx to d:\ebooks\azw8
5. rename the kfx files to azw8 so Kindle Previewer can open them since the KP cannot open kfx files

6. delete d:\ebooks\epub folder
7. export using calibredb all epub files to that folder

[phossler]

Originally Posted by DNSB

I have rarely seen the filename considered part of the metadata.

I was just saying that while the metadata in the book and in the calibre database might have a full and very long title, the file name on disc is truncated to allow it to work across multiple operating systems

[kovidgoyal]

It's a limitation purely for windows. On other OSes calibre does not enforce this restriction. And this restriction is still present on windows despite the registry key because the registry key is a god awful hack. With it enabled random windows software will be unable to see the files, including windows explorer. And you can destroy your library copying it from one computer to another if the state of the registry key is different on the two computers. I prefer to be conservative with data integrity. If someday Microsoft manages to lift this restriction for real, I might reconsider. That day hasnt arrived yet.

[Quoth]

Even without the Registry thing Windows backups and file copies can fail because the total path and filename is over 255 characters. Metadata has the title. The Calibre file names just need to be unique as as short as possible.

[nixR3ad]

I hope this isn't a necro, but I was finally learning templates after 10 years of Calibre for specific this reason.

It's not only Windows that does this. I am using Calibre 7 on Arch linux. This happens to me. I use koreader on my kobo sage with top-level directories to sort my titles by #subject. Ideally, a simplified version would be like

/books/History/Some_Author-Some_Series-01-Some_title.epub

however, if that is very long (I use series so it can be), the path or file name is truncated. This isn't such a big deal when it happens to the filename because koreader shows the metadata title in the filemanager once I'm in that directory, but it may come out one of these random ways:

/books/Hstory
/boks/History
/books/History

It is totally random where they end up, which is kinda sketchy. Even stranger, two books with the same path/name length get truncated in different ways, dividing the bunch. I'd much rather a message telling me the transfer had failed than have the system make arbitrary decisions about where my files land.

It's not noticeable when using Nickel because all browsing is via the database. But sending 50 books on one subject to the e-reader might end up with the same subject scattered in different places. With koreader, this is no good.

I started using some send-to-device templates that mostly work. Since I really only need the top two levels to be 100% correct, I preemptively truncate the title myself like this:

books/{#shelf:||/}{author_sort:sublist(0,1,\,)}-{series:||-}{series_index:re(^(\d)(\.|$),0\1\2)||-}{title:'sublist(sublist($, 0, 1, ':'), 0, 10, '_')'}

This ensures no title shows at all beyond the subtitle separator ':' and the rare book that has a very long main title doesn't have more than 10 words, separated by '_'

It didn't seem to matter if I placed the Subject/Auth/Series/Title on the same line on the filename or as nested directories. It was always shortened.

I think this is more of a vfat bug than an os bug. I'm thinking of trying a regular rsync and see if the same happens. So far, I've only used Calibre for this experiment. ext4 might be a better fs option for those who have that choice, for a few reasons.

[kovidgoyal]

When sending to devices calibre always truncates to 256 as various devices have various limitations.

[chaley]

Originally Posted by nixR3ad

It is totally random where they end up, which is kinda sketchy. Even stranger, two books with the same path/name length get truncated in different ways, dividing the bunch. I'd much rather a message telling me the transfer had failed than have the system make arbitrary decisions about where my files land.

It isn't "totally random". Any "over length" is distributed over the name segments depending on the length of the segments.

Use the template function shorten() to explicitly control how much space is used by each name segment and how the segments are shortened.