Change characters in metadata title and filenames on disk

NickKnaque · 10-21-2019, 09:51 AM

I use Calibre on Windows (7 & 10) and on Linux, in all of those environments I want to save my C++ books to disk leaving C++ as it appears in the title, instead of converting to C__ as it does by default. (I hate this!)

Is there a tweak or something to manage this? I'd rather not hack the Python source as I like to run from exe.

Also, I'd like to have the : in book titles changed to a comma "," (instead of _) both in metadata and in the filename on disk.

All help gratefully received.

Horus68 · 10-21-2019, 11:54 AM

Quote:

Originally Posted by NickKnaque

Also, I'd like to have the : in book titles changed to a comma "," (instead of _) both in metadata and in the filename on disk.

On the : for a comma see here: https://www.mobileread.com/forums/sh...d.php?t=310144

NickKnaque · 10-22-2019, 08:26 AM

Thank you

NickKnaque · 10-22-2019, 10:08 AM

Using title:re() in the template for save-to-disk does not solve the C__ (instead of C++) in the filename, for me. It seems something more fundamental is changing the string after the template has run.

But what, and how can I change it?

theducks · 10-22-2019, 10:19 AM

Quote:

Originally Posted by NickKnaque

Using title:re() in the template for save-to-disk does not solve the C__ (instead of C++) in the filename, for me. It seems something more fundamental is changing the string after the template has run.

But what, and how can I change it?

+ is the file concatenation character in Windows
file1+file2+file3>fileall

NickKnaque · 10-22-2019, 10:25 AM

Thanks, but that does not matter, both Windows & Linux support '+' in filenames.

BetterRed · 10-22-2019, 06:53 PM

Quote:

Originally Posted by NickKnaque

Thanks, but that does not matter, both Windows & Linux support '+' in filenames.

If it's allowable in Linux and Windows (and as far as know on MacOS too), the question is: why is '+' replaced with '_' in the library file name?

Given that '#', '$', '&', '-' etc are not replaced.

I get why \/:*?"<>| are replaced, but not anything else. And I'm not 100% certain it's been ever thus.

BR

DNSB · 10-22-2019, 07:18 PM

Quote:

Originally Posted by BetterRed

If it's allowable in Linux and Windows (and as far as know on MacOS too), the question is: why is '+' replaced with '_' in the library file name?

Given that '#', '$', '&', '-' etc are not replaced.

I get why \/:*?"<>| are replaced, but not anything else. And I'm not 100% certain it's been ever thus.

PC/DR/MS-DOS did not allow the '+' sign as a character in a filename. And I vaguely remember when saving to a floppy (sadly, dating myself there...), you could not use a '+' in a filename saved from Windows 95. Going by a old DRDOS manual, you could not use any of " * + , / : ; < = > ? \ [ ] | in a filename and a space could not be used as the first character of a filename.

BetterRed · 10-22-2019, 07:52 PM

Quote:

Originally Posted by DNSB

PC/DR/MS-DOS did not allow the '+' sign as a character in a filename. And I vaguely remember when saving to a floppy (sadly, dating myself there...), you could not use a '+' in a filename saved from Windows 95. Going by a old DRDOS manual, you could not use any of " * + , / : ; < = > ? \ [ ] | in a filename and a space could not be used as the first character of a filename.

Arrh right, +,.;=[] are not allowed in short (8.3) files names - but with the exception of '+' they are allowed in book file names, hence save names.

BR

JSWolf · 10-23-2019, 12:50 PM

Quote:

Originally Posted by DNSB

PC/DR/MS-DOS did not allow the '+' sign as a character in a filename. And I vaguely remember when saving to a floppy (sadly, dating myself there...), you could not use a '+' in a filename saved from Windows 95. Going by a old DRDOS manual, you could not use any of " * + , / : ; < = > ? \ [ ] | in a filename and a space could not be used as the first character of a filename.

But, if you are able to run Calibre, you will not be running any version of DOS. And you won't be caring about old 8.3 filenames. So I see no reason not to allow +.

Quoth · 10-23-2019, 01:15 PM

You can get filename collision copying from Ext2, Ext3, Ext4, NTFS, ZFS, etc to FAT32, though it might be a problem in the copying utility. It's to do with Case Sensitivity.
Also multiple . can cause problems with the stupid default in Win Explorer of hide file endings.
a . at start and a ~ in certain positions can be a problem
Longer filenames can be fine insitu but cause failure later if total path length for a filesystem or OS is exceeded.
Even now on Windows some less likely three letter or four names ending in : are actually still a problem. Potentially CON, LPT, PUN, not just obvious COM1: to COM4: (or up to 255 on Proper versions of Windows)
CDFS and Joliet are not quite the same (burning to CD) and differ from Mac, NTFS and EXT4.
Some applications don't cope with accented letters.
Some don't like - and others don't like _
& can be a problem
/ or \ may be path separators. Amazingly for a while before DOS4, I think, you could make - be the option char and then DOS used same path separator as UNIX.

There is a filesystem that allows ANY character, which makes for great importing and scary exports...

BetterRed · 10-23-2019, 05:46 PM

None of which explains why I can have a book titled "Programming in C##" and get that name in the output of Save to Disk without any special measures.

But if I have "Programming in C++" I must resort to regex template jiggery-pokery to get that name in the output of Save to Disk.

'+' and '#" are both present in that banned from 8.3 file names list.

BR

JSWolf · 10-23-2019, 06:29 PM

Quote:

Originally Posted by BetterRed

None of which explains why I can have a book titled "Programming in C##" and get that name in the output of Save to Disk without any special measures.

But if I have "Programming in C++" I must resort to regex template jiggery-pokery to get that name in the output of Save to Disk.

'+' and '#" are both present in that banned from 8.3 file names list.

BR

And who would be using 8.3 legacy filenames when using Windows?

BetterRed · 10-23-2019, 06:44 PM

Quote:

Originally Posted by JSWolf

And who would be using 8.3 legacy filenames when using Windows?

No one Jon.

But that doesn't explain why a book title of "Programming in C++" requires regex jiggery-pokery in StD templates - and that is the issue under consideration.

BR

kovidgoyal · 10-23-2019, 11:49 PM

If you wish to re-enable + it is a one line chage to calibre's source code, see line 109 in calibre/__init_.py -- as for why it is disabled it is because it caused actual problems with something, what that was I no longer recall.

10-21-2019, 09:51 AM	#1
NickKnaque Variable Posts: 13 Karma: 10 Join Date: Jan 2017 Location: 3rd quadrant, alpha section Device: Kobo Aura H2O (original)	Change characters in metadata title and filenames on disk I use Calibre on Windows (7 & 10) and on Linux, in all of those environments I want to save my C++ books to disk leaving C++ as it appears in the title, instead of converting to C__ as it does by default. (I hate this!) Is there a tweak or something to manage this? I'd rather not hack the Python source as I like to run from exe. Also, I'd like to have the : in book titles changed to a comma "," (instead of _) both in metadata and in the filename on disk. All help gratefully received.

10-22-2019, 10:08 AM	#4
NickKnaque Variable Posts: 13 Karma: 10 Join Date: Jan 2017 Location: 3rd quadrant, alpha section Device: Kobo Aura H2O (original)	C++ -> C__ Using title:re() in the template for save-to-disk does not solve the C__ (instead of C++) in the filename, for me. It seems something more fundamental is changing the string after the template has run. But what, and how can I change it?

10-23-2019, 05:46 PM	#12
BetterRed null operator (he/him) Posts: 22,018 Karma: 30277294 Join Date: Mar 2012 Location: Sydney Australia Device: none	None of which explains why I can have a book titled "Programming in C##" and get that name in the output of Save to Disk without any special measures. But if I have "Programming in C++" I must resort to regex template jiggery-pokery to get that name in the output of Save to Disk. '+' and '#" are both present in that banned from 8.3 file names list. BR Last edited by BetterRed; 10-23-2019 at 06:24 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Metadata Plugboard to change title of same-title books in series for Kobo Touch	il_mix	Library Management	5	03-15-2018 05:59 PM
Book title displays differently in Kindle after metadata change	ggurman	Library Management	10	02-09-2016 03:10 PM
Can't change title metadata of .mobi file?	dkgonda	Library Management	1	03-04-2012 07:20 PM
Filenames to metadata, preserving filenames.	nitrogun	Calibre	5	09-13-2010 11:50 PM
PDF Filenames vs Metadata Title	clintbradford	Calibre	0	07-13-2010 12:50 AM

10-22-2019, 08:26 AM	#3
NickKnaque Variable Posts: 13 Karma: 10 Join Date: Jan 2017 Location: 3rd quadrant, alpha section Device: Kobo Aura H2O (original)	Thank you

10-22-2019, 10:25 AM	#6
NickKnaque Variable Posts: 13 Karma: 10 Join Date: Jan 2017 Location: 3rd quadrant, alpha section Device: Kobo Aura H2O (original)	Thanks, but that does not matter, both Windows & Linux support '+' in filenames.

10-23-2019, 01:15 PM	#11
Quoth Still reading Posts: 15,008 Karma: 111111255 Join Date: Jun 2017 Location: Ireland Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper	You can get filename collision copying from Ext2, Ext3, Ext4, NTFS, ZFS, etc to FAT32, though it might be a problem in the copying utility. It's to do with Case Sensitivity. Also multiple . can cause problems with the stupid default in Win Explorer of hide file endings. a . at start and a ~ in certain positions can be a problem Longer filenames can be fine insitu but cause failure later if total path length for a filesystem or OS is exceeded. Even now on Windows some less likely three letter or four names ending in : are actually still a problem. Potentially CON, LPT, PUN, not just obvious COM1: to COM4: (or up to 255 on Proper versions of Windows) CDFS and Joliet are not quite the same (burning to CD) and differ from Mac, NTFS and EXT4. Some applications don't cope with accented letters. Some don't like - and others don't like _ & can be a problem / or \ may be path separators. Amazingly for a while before DOS4, I think, you could make - be the option char and then DOS used same path separator as UNIX. There is a filesystem that allows ANY character, which makes for great importing and scary exports...

10-23-2019, 11:49 PM	#15
kovidgoyal creator of calibre Posts: 45,609 Karma: 28549044 Join Date: Oct 2006 Location: Mumbai, India Device: Various	If you wish to re-enable + it is a one line chage to calibre's source code, see line 109 in calibre/__init_.py -- as for why it is disabled it is because it caused actual problems with something, what that was I no longer recall.

Advert

Advert