ripMIME icon indicating copy to clipboard operation
ripMIME copied to clipboard

Fails on very long filenames

Open gvoncken opened this issue 4 years ago • 2 comments

First of all, many thanks for ripmime!

I sometimes encounter files containing attachments with very long filenames. "Very long" means longer than 255 characters (on my Linux system). This is an error message I recently got:

mime.c:2337:MIME_generate_multiple_hardlink_filenames:WARNING: While trying to create '(...)' link to '(...)' (File name too long)

On non Linux filesystems (HFS, FAT, ...) the maximum filename length can even be less than 255 characters.

Suggestion for handling the problem:

  • Query the max. file name size with the help of function pathconf (see http://www.gnu.org/software/libc/manual/html_node/Pathconf.html, parameter _PC_NAME_MAX)
  • If a file is to be created with a name longer than that value: Shorten the filename to the max value minus some spare characters.
  • Those spare characters are needed if a file with that name already exists. In that case, renaming could be done according to the options --overwrite, --unique-names, --prefix, --postfix and --infix.
  • Optionally, the spare characters could include some string hinting that the filename was shortened and does not correspond to the original filename. For example: "AttachmentThatReallyHasSomeVeryLongFilename" would become "AttachmentThatReallyHasSomeVe_shortened".
  • If a filename needs to be shortened, ripmime could inform about it on stdout (the message would include the original filename) .
  • ripmime could even refuse to work on file systems whose maximum filename length is less then a certain value.

Thanks again for this great tool and best greetings!

gvoncken avatar Dec 03 '21 08:12 gvoncken

Hello,

    Interesting situation. I'll have to have a look at the code based on what you've reported.  Been a very long time since I broke open the archive for ripMIME, so this should be quite interesting.

    I might have to look at truncating+suffix to resolve the issue.

Regards, Paul L Daniels.

On 3/12/21 6:23 pm, gvoncken wrote:

First of all, many thanks for ripmime!

I sometimes encounter files containing attachments with very long filenames. "Very long" means longer than 255 characters (on my Linux system). This is an error message I recently got:

mime.c:2337:MIME_generate_multiple_hardlink_filenames:WARNING:
While trying to create '(...)' link to '(...)' (File name too long)

On non Linux filesystems (HFS, FAT, ...) the maximum filename length can even be less than 255 characters.

Suggestion for handling the problem:

  • Query the max. file name size with the help of function pathconf (see http://www.gnu.org/software/libc/manual/html_node/Pathconf.html http://www.gnu.org/software/libc/manual/html_node/Pathconf.html, parameter _PC_NAME_MAX)
  • If a file is to be created with a name longer than that value: Shorten the filename to the max value minus some spare characters.
  • Those spare characters are needed if a file with that name already exists. In that case, renaming could be done according to the options --overwrite, --unique-names, --prefix, --postfix and --infix.
  • Optionally, the spare characters could include some string hinting that the filename was shortened and does not correspond to the original filename. For example: "AttachmentThatReallyHasSomeVeryLongFilename" would become "AttachmentThatReallyHasSomeVe_shortened".
  • If a filename needs to be shortened, ripmime could inform about it on stdout (the message would include the original filename) .
  • ripmime could even refuse to work on file systems whose maximum filename length is less then a certain value.

Thanks again for this great tool and best greetings!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/inflex/ripMIME/issues/18, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLF7L53PMHGBHFKXFIJJYLUPB47ZANCNFSM5JJDJLNA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Paul L Daniels - http://pldaniels.com A.B.N. 19 500 721 806

inflex avatar Dec 03 '21 08:12 inflex

Thanks for the very fast answer, Paul.

I re-read my message; there's one point where I wasn't precise: The max. Linux filename length is not expressed in characters. It's a number of bytes!

Example: The filename Привет.jpg has 10 characters and is 16 bytes long. A 5 character filename like 𓂀𓁆𓀽𓀿𓃀 even consumes 20 bytes in UTF-8 (and with only 64 ancient Egypt symbols you get a "filename too long" error).

As ripmime is looking at filenames as char[], truncation could become tricky. There is the risk of cutting the filename in the middle of a multi-byte UTF-8 sequence, probably leading to new problems.

Maybe, the best way for treating too long filenames is not truncation. Replacing the whole name would be much easier and safer: Renamed_file_1, Renamed_file_2 etc.

The main thing is extracting the file. In case I need the original filename I easily can grep it if ripmime puts an info message on stdout.

Guy

gvoncken avatar Dec 03 '21 11:12 gvoncken