Better storage for my Sage?

[nixR3ad]

IIRC, I had a kobo years ago with internal ext4 storage. I know this because I have a painful memory of being very intoxicated and converting it to btrfs. It bricked. Many years later I own a Sage. It's a FAT format which is very limiting. Are people creating ext4 partitions? Is that what I did back then? Memories are fuzzy, but I require a filesystem that doesn't truncate the paths of files when I send them to the device.

[DNSB]

Originally Posted by nixR3ad

IIRC, I had a kobo years ago with internal ext4 storage. I know this because I have a painful memory of being very intoxicated and converting it to btrfs. It bricked. Many years later I own a Sage. It's a FAT format which is very limiting. Are people creating ext4 partitions? Is that what I did back then? Memories are fuzzy, but I require a filesystem that doesn't truncate the paths of files when I send them to the device.

Converting the exposed partition to another format is both very easy to do and not that easy to do. It will require that you modify various scripts to change multiple settings such the flavour of fsck used. This will also break on a firmware update since the scripts will be overwritten. You may also want to remember that the Sage does not have removable internal storage so if you brick it, you have an expensive paperweight.

As for truncating file names, since I use calibre, it doesn't matter what file system I use, the file names will be truncated since calibre aims for the LCD. As for the effect of truncating the file names, it is a non-starter for me since Kobo uses the information from the book metadata for everything. You had noticed the common complaints that Kobo default software does not allow you to browse by file name/paths? From comments I've read, most people consider Kobo's search to do a far better job of locating authors, books, series, subtitles, etc. than any directory structure can offer.

You can console yourself that 2/3 of the partitions will still be ext4.

[Aleron Ives]

How is FAT32 limiting? Do you have a 5 GiB e-book you want to read? I see full filenames when I connect to a computer, not 8.3 DOS names.

[Sirtel]

Originally Posted by DNSB

As for the effect of truncating the file names, it is a non-starter for me since Kobo uses the information from the book metadata for everything. You had noticed the common complaints that Kobo default software does not allow you to browse by file name/paths? From comments I've read, most people consider Kobo's search to do a far better job of locating authors, books, series, subtitles, etc. than any directory structure can offer.

I suspect the OP wants to use KOReader, hence the need for filenames.

[Uncle Robin]

Originally Posted by Aleron Ives

How is FAT32 limiting? Do you have a 5 GiB e-book you want to read? I see full filenames when I connect to a computer, not 8.3 DOS names.

This is what I was wondering.

[DNSB]

Originally Posted by Aleron Ives

How is FAT32 limiting? Do you have a 5 GiB e-book you want to read? I see full filenames when I connect to a computer, not 8.3 DOS names.

I suspect that the OP wants to be able to use a path/filename length greater than the 32,760 Unicode characters (maximum 255 per block) allowed by FAT32. Given the complex directory structure required for a directory based library to allow easily locating a book, path lengths can and do get ridiculously long.

For compatibility reasons, calibre imposes a maximum 185(?) character limit on path/filename length which can lead to truncation with moderately complex setups such as using the directory for tags, series, multiple authors, subtitles and anything else that you can think of when sending books to your ereader.

[JSWolf]

What eBook has a filename longer than 185 characters?

[DNSB]

Originally Posted by JSWolf

What eBook has a filename longer than 185 characters?

Jon, that is the total for the file path and file name. As for which books have filenames longer than 185 characters? Try an anthology with 26 authors where the file name is title - authors.

[Aleron Ives]

Some people sure come up with unwieldy naming conventions.

[DNSB]

Originally Posted by Aleron Ives

Some people sure come up with unwieldy naming conventions.

Add in the people who want to be able to use series, multiple tags, genre, etc. as part of the file name/path. People whom, IMHO, are stuck back in the 1980s.

A few years back, one person was complaining that they had a very carefully crafted directory structure and they could not send it to their Kobo and that when they tried calibre, it turned their directory structure into a pile of crap. When I asked why they were so concerned about directory structure on a Kobo or in calibre, the response was how else could they locate a book to read? Evidently using calibre or their Kobo's ability to search on various criteria was not acceptable in their opinion.

After a few more rounds back and forth in PMs about calibre not touching the original directory structure unless you use auto-add which is specific to one directory, I gave up on debating what amounted to a religious dispute about search vs. directory structure.

[JSWolf]

Originally Posted by DNSB

Jon, that is the total for the file path and file name. As for which books have filenames longer than 185 characters? Try an anthology with 26 authors where the file name is title - authors.

For an anthology, I don't use author names. I put in the editor(s) instead. Solves the too unwieldy problem.

[JSWolf]

Originally Posted by DNSB

Add in the people who want to be able to use series, multiple tags, genre, etc. as part of the file name/path. People whom, IMHO, are stuck back in the 1980s.

A few years back, one person was complaining that they had a very carefully crafted directory structure and they could not send it to their Kobo and that when they tried calibre, it turned their directory structure into a pile of crap. When I asked why they were so concerned about directory structure on a Kobo or in calibre, the response was how else could they locate a book to read? Evidently using calibre or their Kobo's ability to search on various criteria was not acceptable in their opinion.

After a few more rounds back and forth in PMs about calibre not touching the original directory structure unless you use auto-add which is specific to one directory, I gave up on debating what amounted to a religious dispute about search vs. directory structure.

I don't actually like directory structure based eBook storage. It's too fixed in it's ways. I prefer the calibre way and I can find something much easier. Kobo makes it fairly easy to find something as well.

[DNSB]

Originally Posted by JSWolf

For an anthology, I don't use author names. I put in the editor(s) instead. Solves the too unwieldy problem.

Whereas for me, I allow calibre to list all the author names plus any editor names ( postfixed with (ed) ) names. The template for send to device limits the use of the author name to the first entry in the list since the metadata will allow search for any of the authors in either calibre or my Kobo.

Doing this with a directory structure leads to insanely complex structures which is where I stepped out of that years back discussion.

To argue with a man who has renounced the use and authority of reason, and whose philosophy consists in holding humanity in contempt, is like administering medicine to the dead, or endeavoring to convert an atheist by scripture.—Thomas Paine

[nixR3ad]

Mysuecase is specific. I don't use metadata lookups. I use koreader. I actually don't mind that the filename be truncated, beause in the target directory, koreader displays metadata. But when I dort things into

/books/History/Author/title.epub
/books/Psychology/Author/title.epub
(it's actually more complicated than that)
I randomly get paths like

/books/Hstry/Auhor/title.epub
/boks/History/Auor/title.epub
/books/Psychology/Ar/title.epub
/boks/Psyclgy/Author/title.epub

When there are series in the paths and/or subtitles for academic titles, this makes finding things in a reader packed with 300 books difficult at the worst; unpleasant, and ugly at the least.
Reformatting a drive is a comfort zone. I'm a published linux support analyst. the path to the career began because of my first Nook and Kindle jailbreak enjoyments. There are a few ways to do it, but I would like to hear what works for others first. Someone posted a write-up elsewhere of using loopback images for a full Alpine environment which sounds kinda neat

My secondary need for ext4 (or similar) is the use of links to put books into multiple #subject directories like "anthologies" or "short fiction." I know Koreader has its own "shortcuts" feature, which is great, but this is a custom method that I'd worked out on my pc, however vfat doesn't support links (or other useful features).

I'm curious to see if the 4.x kernel the Sage uses includes btrfs support. It did not last time, but kernels can be compiled. Getting the userspace btrfs-progs onto it wouldn't be impossible, and I'd have reflink clones, compression, data protection, snapshots of config directories, and most importantly... write leveling on the card. Anyway, a man can dream...

[nixR3ad]

if anyone does need a method to avoid random vfat truncation of top-level directories, here is my send-to-device template. It sends to a "books" directory, then the #shelf.

The rest is a single filename (no author, series dirs) so that koreader will just show the metadata in the #shelf directory. The author is shortened, and the "title" part ensures the filenames don't include subtitles, and any main titles longer than 10 words get shortened to 10, preserving the '/books/#shelf' part of the path.

This wasn't mine, as I'm new to the template language, but I did hack it together from various examples I'd found in this forum.

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