my pull request (#216) implements truncating the base-filename at 230 bytes and adds --filename-mode asin_only which allows the user to use only the asin as the base-filename.

@devvythelopper
Thank you for your pr. It looks fine, but I will try it out first for drawbacks. My planned solution was to check the maximum name length like this solution. Now I have to decide, which way is the best.

The problem with the other solution is, that it might cut off the suffixes -annotations.json (and you'd have to code around that). Also depending on how you implemented writing to files, you might have to touch a multitude of places in your code.

The problem with my solution is, that it does not check for actual filesystem limits. I suppose one should add os.statvfs(file_parent_path).f_namemax to my solution and substract some 25 bytes (UTF-8 characters can take up to 4 bytes and most filesystems limit to number of bytes, not to number of characters).

there is one drawback I've thought of btw:

say a user successfully has downloaded an audiobook that has a very long filename, say 235 bytes. Adding your extensions the filenames may be between 240 and 250 bytes. if we cut the filenames off now at 230, this audiobook will be redownloaded if the user specifies --all. What you could do to mitigate this is to not use 230 bytes but actually look at all your suffixes, and look which is the longest. Then take os.statvfs(file_parent_path).f_namemax - max_suffix_length as the byte length limit. Any book already successfully downloaded does not have a filename longer than this.

Or you leave it as it is now for simplicity's sake, and you'll be safe if in the future some longer suffixes might be added. I personally would leave it as it is now. It's good enough and users will adjust.