Ebook filename conversion at import - suggestions

millirem · 06-21-2020, 05:18 PM

I know this has been talked about many times because I researched the forums here. But I have possibly a couple new comments/insights on the issue.

Like many people, my concern is the shortening of filenames upon import, which impacts the ability to find files via external search tools.

1. To the argument that the search capabilities within Calibre are already very good - undeniable. But myself and others often have favored system-wide search tools - in my case the excellent tool Everything ( https://www.voidtools.com ) - and it is a good general principle that an application interferes with users' system tools and preferred practices as little as possible. Because Calibre shortens file names, searches for ebooks which I know I have on my system often unexpectedly fail for me when using the Everything tool. Finding the books then requires switching to Calibre as a second search attempt. To avoid these double searches, I have to constantly remember that Calibre abbreviates names and skip using Everything when searching for ebooks, which is error-prone.

2. I understand the concern about Calibre's import process not causing the path names in its database to exceed system limits, which is logical. From what I understand, the method that Calibre uses to avoid this is assuming the worst case, for any possible database location in the filesystem. Instead, perhaps Calibre could calculate the actual database location root path length, and thus be able to loosen the restrictions on ebook filename length. For example, if a user puts their Calibre database root in a directory named C:\c, there would be freedom to allow imported ebook filenames to still be very long. If a user later wants to move their Calibre database location to a directory with a longer pathname, Calibre could be programmed to handle this move process and only *then* shorten the ebook filenames, as necessary.

Thanks for consideration.

ownedbycats · 06-21-2020, 06:15 PM

The problem with #2 that I can see is that somebody can physically move their library to another location. If they move it to a location with a longer path it might cause hiccups when a filename suddenly hits the limit.

I use Everything and rarely have trouble finding an eBook with it. But I don't type in entire titles at once, just the first few characters/words.

BetterRed · 06-21-2020, 07:12 PM

@millirem - Calibre runs on multiple versions of three operating systems and it supports seven or more file systems, collectively they impose limits not only on path lengths, but also on character sets and case sensitivity. The formation of the library folder and file names must take each of these factors into account.

And further to obc's response, someone might want to move or access their library on another computer, running a different operating and/or file system.

BR

millirem · 06-21-2020, 07:35 PM

It could be required that Calibre performs moves of its own library, and therefore manage filename length calculations and renaming as necessary. That seems like a proper concern for Calibre, rather than assuming users be allowed to move its files by other, external means.

Often a book title has critical words near the middle or end of its title, and it's those words that can be truncated by Calibre's file renaming.

The variety of file system limitations on different platforms is I agree a problem. Those limitations could be built into Calibre perhaps; perhaps also there is a file system abstraction in the Python or other libraries used to build Calibre? I also think this effort is worth some consideration based on the sheer number of Calibre users who have complained about this issue over the years.

BetterRed · 06-21-2020, 08:14 PM

The number of potential users who have complained, as opposed to enquired, over the last 12 years would be less than a hundred. In the context of there being 3 million active users that hardly qualifies as a 'sheer number'.

What some have done is to use the library manager as a 'workbench' to collect and correct metadata, do format conversions, edit format files… etc. And then use the Save to Disk tool to create a bespoke folder structure with bespoke file names, and then delete the book from the library.

The way library folder and file names are formulated is not going to change, so we're wasting our time discussing it any further. However, because calibre is open source you can download the source and make it behave exactly as you want.

BR

06-21-2020, 05:18 PM	#1
millirem Junior Member Posts: 3 Karma: 10 Join Date: Jan 2015 Device: PC	Ebook filename conversion at import - suggestions I know this has been talked about many times because I researched the forums here. But I have possibly a couple new comments/insights on the issue. Like many people, my concern is the shortening of filenames upon import, which impacts the ability to find files via external search tools. 1. To the argument that the search capabilities within Calibre are already very good - undeniable. But myself and others often have favored system-wide search tools - in my case the excellent tool Everything ( https://www.voidtools.com ) - and it is a good general principle that an application interferes with users' system tools and preferred practices as little as possible. Because Calibre shortens file names, searches for ebooks which I know I have on my system often unexpectedly fail for me when using the Everything tool. Finding the books then requires switching to Calibre as a second search attempt. To avoid these double searches, I have to constantly remember that Calibre abbreviates names and skip using Everything when searching for ebooks, which is error-prone. 2. I understand the concern about Calibre's import process not causing the path names in its database to exceed system limits, which is logical. From what I understand, the method that Calibre uses to avoid this is assuming the worst case, for any possible database location in the filesystem. Instead, perhaps Calibre could calculate the actual database location root path length, and thus be able to loosen the restrictions on ebook filename length. For example, if a user puts their Calibre database root in a directory named C:\c, there would be freedom to allow imported ebook filenames to still be very long. If a user later wants to move their Calibre database location to a directory with a longer pathname, Calibre could be programmed to handle this move process and only then shorten the ebook filenames, as necessary. Thanks for consideration.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Import Author And Title From Filename & Import Other Tags And Cover From File	DazJWood	Library Management	25	10-06-2021 10:18 AM
Import on Filename changes mid import due to book error	Vortex	Calibre	3	12-05-2014 11:49 AM
Import Filename	jhs75	Library Management	4	09-26-2013 01:02 AM
Import ebook conversion in python script	erollisi	Calibre	1	08-19-2010 09:43 PM

06-21-2020, 06:15 PM	#2
ownedbycats Custom User Title Posts: 10,970 Karma: 75337983 Join Date: Oct 2018 Location: Canada Device: Kobo Libra H2O, formerly Aura HD	The problem with #2 that I can see is that somebody can physically move their library to another location. If they move it to a location with a longer path it might cause hiccups when a filename suddenly hits the limit. I use Everything and rarely have trouble finding an eBook with it. But I don't type in entire titles at once, just the first few characters/words. Last edited by ownedbycats; 06-21-2020 at 06:17 PM.

06-21-2020, 07:12 PM	#3
BetterRed null operator (he/him) Posts: 21,720 Karma: 29711016 Join Date: Mar 2012 Location: Sydney Australia Device: none	@millirem - Calibre runs on multiple versions of three operating systems and it supports seven or more file systems, collectively they impose limits not only on path lengths, but also on character sets and case sensitivity. The formation of the library folder and file names must take each of these factors into account. And further to obc's response, someone might want to move or access their library on another computer, running a different operating and/or file system. BR

06-21-2020, 07:35 PM	#4
millirem Junior Member Posts: 3 Karma: 10 Join Date: Jan 2015 Device: PC	It could be required that Calibre performs moves of its own library, and therefore manage filename length calculations and renaming as necessary. That seems like a proper concern for Calibre, rather than assuming users be allowed to move its files by other, external means. Often a book title has critical words near the middle or end of its title, and it's those words that can be truncated by Calibre's file renaming. The variety of file system limitations on different platforms is I agree a problem. Those limitations could be built into Calibre perhaps; perhaps also there is a file system abstraction in the Python or other libraries used to build Calibre? I also think this effort is worth some consideration based on the sheer number of Calibre users who have complained about this issue over the years.

06-21-2020, 08:14 PM	#5
BetterRed null operator (he/him) Posts: 21,720 Karma: 29711016 Join Date: Mar 2012 Location: Sydney Australia Device: none	The number of potential users who have complained, as opposed to enquired, over the last 12 years would be less than a hundred. In the context of there being 3 million active users that hardly qualifies as a 'sheer number'. What some have done is to use the library manager as a 'workbench' to collect and correct metadata, do format conversions, edit format files… etc. And then use the Save to Disk tool to create a bespoke folder structure with bespoke file names, and then delete the book from the library. The way library folder and file names are formulated is not going to change, so we're wasting our time discussing it any further. However, because calibre is open source you can download the source and make it behave exactly as you want. BR

Advert

Advert