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.