[GH-ISSUE #7] Failure to open attachments

kerem commented

2026-03-03 01:18:50 +03:00

Owner

Originally created by @Kabouik on GitHub (Jan 13, 2020).
Original GitHub issue: https://github.com/d99kris/nmail/issues/7

First of all, thanks for making nmail. Not being used to terminal MUAs, I wanted to try and started with Neomutt but was overwhelmed by the number of controls and configuration settings required to make it fully functional, then tried sup but disliked the lack of sidebar and again, numerous different controls (they all have a purpose, I know, but nmail does a better job at summarizing most important keys on the screen). No sidebar in nmail either, but a very straightforward UI including one listing folders, very much like a sidebar. I also love that attachments are open as temporary files by default. Great stuff.

I am trying to open image attachments but everything I try in main.conf fails, be it xdg-open, viewnior or ristretto. I am running Ubuntu xfce4 in chroot from a Sailfish OS device (with XWayland). I installed gtk2-engines-pixbuf due to multiple warnings in log.txt, which worked, but I am still getting this after a session in which I try to open attachments:

2020-01-13 02:31:11.599 | INFO  | starting nmail v1.12  (main.cpp:103)
2020-01-13 02:31:11.599 | INFO  | using Linux/gcc-8.3.0  (main.cpp:107)
2020-01-13 02:31:15.561 | ERROR | mailimap_uid_fetch(m_Imap, set, fetch_type, &fetch_result) = 9  (imap.cpp:349)
2020-01-13 02:32:18.415 | INFO  | exiting nmail  (main.cpp:258

Exemple with image files and ext_viewer_cmd=xdg-open in main.conf:

It's the same if I configure xdg-open to use ristretto instead of viewnior, except ristretto just stays empty without the warning message. I checked document files too, they open Libreoffice but the temp files are not found. I checked the tmp/ folder without quitting nmail, and indeed no file appearing in there after trying to open attachments in nmail. Every attempts seems to try creating a new unique filename, if I believe viewnior and Libreoffice's "/home/user/.nmail/tmp/tempfile.xxxx does not exist" errors.

[Edit] In another session with --verbose on, I could not find anything useful in log.txt.

Originally created by @Kabouik on GitHub (Jan 13, 2020). Original GitHub issue: https://github.com/d99kris/nmail/issues/7 First of all, thanks for making nmail. Not being used to terminal MUAs, I wanted to try and started with Neomutt but was overwhelmed by the number of controls and configuration settings required to make it fully functional, then tried sup but disliked the lack of sidebar and again, numerous different controls (they all have a purpose, I know, but nmail does a better job at summarizing most important keys on the screen). No sidebar in nmail either, but a very straightforward UI including one listing folders, very much like a sidebar. I also love that attachments are open as temporary files by default. Great stuff. I am trying to open image attachments but everything I try in `main.conf` fails, be it `xdg-open`, `viewnior` or `ristretto`. I am running Ubuntu xfce4 in chroot from a Sailfish OS device (with XWayland). I installed `gtk2-engines-pixbuf` due to multiple warnings in `log.txt`, which worked, but I am still getting this after a session in which I try to open attachments: ``` 2020-01-13 02:31:11.599 | INFO | starting nmail v1.12 (main.cpp:103) 2020-01-13 02:31:11.599 | INFO | using Linux/gcc-8.3.0 (main.cpp:107) 2020-01-13 02:31:15.561 | ERROR | mailimap_uid_fetch(m_Imap, set, fetch_type, &fetch_result) = 9 (imap.cpp:349) 2020-01-13 02:32:18.415 | INFO | exiting nmail (main.cpp:258 ``` Exemple with image files and `ext_viewer_cmd=xdg-open` in `main.conf`: ![Screenshot_20200113_001](https://user-images.githubusercontent.com/7107523/72229385-8595f380-35ae-11ea-8fd7-593060352db2.png) It's the same if I configure `xdg-open` to use ristretto instead of viewnior, except ristretto just stays empty without the warning message. I checked document files too, they open Libreoffice but the temp files are not found. I checked the `tmp/` folder without quitting nmail, and indeed no file appearing in there after trying to open attachments in nmail. Every attempts seems to try creating a new unique filename, if I believe viewnior and Libreoffice's "/home/user/.nmail/tmp/tempfile.xxxx does not exist" errors. [Edit] In another session with `--verbose on`, I could not find anything useful in [log.txt](https://github.com/d99kris/nmail/files/4051932/log.txt).

kerem closed this issue

2026-03-03 01:18:50 +03:00

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@d99kris commented on GitHub (Jan 13, 2020):

Hi! Thanks for the extensive bug report, much appreciated! You've already answered almost all the questions I would ask. :)

Could you try saving an attachment and open outside nmail (just to ensure nmail properly processes the attachment)? In the attachment view you can press s and then press enter to save in current working dir, and then check if the file can be opened manually.

Regarding how nmail is supposed to work: When opening an attachment, nmail saves the attachment in a temporary file and launches the command specified by ext_viewer_cmd setting, with the path to the temporary file as only argument. Once the command has completed/exited, the temporary file is immediately deleted, which can make it a little more tricky to debug.

@d99kris commented on GitHub (Jan 13, 2020): Hi! Thanks for the extensive bug report, much appreciated! You've already answered almost all the questions I would ask. :) Could you try saving an attachment and open outside nmail (just to ensure nmail properly processes the attachment)? In the attachment view you can press `s` and then press `enter` to save in current working dir, and then check if the file can be opened manually. Regarding how nmail is supposed to work: When opening an attachment, nmail saves the attachment in a temporary file and launches the command specified by `ext_viewer_cmd` setting, with the path to the temporary file as only argument. Once the command has completed/exited, the temporary file is immediately deleted, which can make it a little more tricky to debug.

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@Kabouik commented on GitHub (Jan 13, 2020):

Thanks for the fast answer. I can confirm saving the file works as expected: the file was properly downloaded and could be opened with the applications I tried when just "opening" from nmail.

The temporary file "cuisine" might be a bit trickier to debug, but it really is nice as it avoids cluttering the disk for no reason with files that would be hard to find again without using nmail anyway. I really like that (though a prompt to choose where to save files would be nice, but saving in pwd form where nmail was launched is relevant too).

@Kabouik commented on GitHub (Jan 13, 2020): Thanks for the fast answer. I can confirm saving the file works as expected: the file was properly downloaded and could be opened with the applications I tried when just "opening" from nmail. The temporary file "cuisine" might be a bit trickier to debug, but it really is nice as it avoids cluttering the disk for no reason with files that would be hard to find again without using nmail anyway. I really like that (though a prompt to choose where to save files would be nice, but saving in `pwd` form where nmail was launched is relevant too).

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@d99kris commented on GitHub (Jan 13, 2020):

Thank you! OK, I think I need to add some more debug logging in nmail in the portion that executes the external command. No time today though unfortunately, but I'll get back soon.

@d99kris commented on GitHub (Jan 13, 2020): Thank you! OK, I think I need to add some more debug logging in `nmail` in the portion that executes the external command. No time today though unfortunately, but I'll get back soon.

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@Kabouik commented on GitHub (Jan 13, 2020):

For what it's worth, I have installed nmail on my computer running Solus and am experiencing the same issue with all kinds of attachments (html, text, image, pdf). The default applications are properly called, but fail to find the files. I've tried running nmail as root, but still the same issue.

If I monitor the ~/.nmail/tmp folder when attempting to open an attachment, I can confirm that no file is being created, even temporarily.

@Kabouik commented on GitHub (Jan 13, 2020): For what it's worth, I have installed nmail on my computer running Solus and am experiencing the same issue with all kinds of attachments (html, text, image, pdf). The default applications are properly called, but fail to find the files. I've tried running nmail as root, but still the same issue. If I monitor the `~/.nmail/tmp` folder when attempting to open an attachment, I can confirm that no file is being created, even temporarily.

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@d99kris commented on GitHub (Jan 14, 2020):

Ok thanks for testing another distro. Since the correct application is launched I have a feeling there's an issue with how nmail launches the application. I suspect that xdg-open returns immediately when being called, and thus nmail proceeds to delete the temporary file (before the external program has loaded the file). I have only tested nmail a little on Linux (Ubuntu 18.04) but I have not seen this issue (mainly tested image attachments). On Mac the launching program is open -Wn which always waits for the called program to terminate. Perhaps xdg-open does not always do that.

I don't have a Linux system with GUI available at the moment, but perhaps you could test running xdg-open manually on some local file, from the command line and see if it immediately returns (before the viewing application has terminated) or not?

If it does return immediately I have some idea on how I can fix it.

In parallel I'll look at adding some logging.

@d99kris commented on GitHub (Jan 14, 2020): Ok thanks for testing another distro. Since the correct application is launched I have a feeling there's an issue with how `nmail` launches the application. I suspect that `xdg-open` returns immediately when being called, and thus `nmail` proceeds to delete the temporary file (before the external program has loaded the file). I have only tested `nmail` a little on Linux (Ubuntu 18.04) but I have not seen this issue (mainly tested image attachments). On Mac the launching program is `open -Wn` which always waits for the called program to terminate. Perhaps `xdg-open` does not always do that. I don't have a Linux system with GUI available at the moment, but perhaps you could test running `xdg-open` manually on some local file, from the command line and see if it immediately returns (before the viewing application has terminated) or not? If it does return immediately I have some idea on how I can fix it. In parallel I'll look at adding some logging.

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@d99kris commented on GitHub (Jan 14, 2020):

I've added some logging in 9844808 which could also help determine in the external command xdg-open is exiting immediately or not.

@d99kris commented on GitHub (Jan 14, 2020): I've added some logging in 9844808 which could also help determine in the external command `xdg-open` is exiting immediately or not.

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@Kabouik commented on GitHub (Jan 14, 2020):

I can confirm xdg-open returns immediately (i.e., the terminal is not staying in a busy state as it does with other commands, and I cannot close the opened application by hitting ctrl+c in the terminal). When monitoring the actual nmail tmp/ folder, I could not see any file being created, even briefly, but maybe there is a reason for that.

I have not tried your commit yet, let me know if my description is clear enough or if you prefer me to git pull and build again.

@Kabouik commented on GitHub (Jan 14, 2020): I can confirm `xdg-open` returns immediately (*i.e.*, the terminal is not staying in a busy state as it does with other commands, and I cannot close the opened application by hitting `ctrl+c` in the terminal). When monitoring the actual nmail `tmp/` folder, I could not see any file being created, even briefly, but maybe there is a reason for that. I have not tried your commit yet, let me know if my description is clear enough or if you prefer me to git pull and build again.

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@d99kris commented on GitHub (Jan 16, 2020):

I've changed the behaviour of nmail now, to not delete temporary files for external viewing immediately after the external viewing command exits. Instead the temporary files are deleted when the user navigates away from the "Message Parts" / "Attachments" view.

Please help check if it resolves the problems you were seeing. Thanks!

@d99kris commented on GitHub (Jan 16, 2020): I've changed the behaviour of `nmail` now, to not delete temporary files for external viewing immediately after the external viewing command exits. Instead the temporary files are deleted when the user navigates away from the "Message Parts" / "Attachments" view. Please help check if it resolves the problems you were seeing. Thanks!

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@d99kris commented on GitHub (Jan 16, 2020):

I also found and fixed a bug (in the same commit) where nmail would fail to open attachments in an external viewer if the path (or filename) contained a space.

@d99kris commented on GitHub (Jan 16, 2020): I also found and fixed a bug (in the same commit) where `nmail` would fail to open attachments in an external viewer if the path (or filename) contained a space.

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@Kabouik commented on GitHub (Jan 16, 2020):

Fantastic, I can confirm it is fixed. Thanks a lot. I must say I really like the way nmail handles attachments as temporary files.

@Kabouik commented on GitHub (Jan 16, 2020): Fantastic, I can confirm it is fixed. Thanks a lot. I must say I really like the way nmail handles attachments as temporary files.

kerem commented

2026-03-03 01:18:51 +03:00

Author

Owner

@d99kris commented on GitHub (Jan 16, 2020):

Great! Thanks for testing/confirming!

@d99kris commented on GitHub (Jan 16, 2020): Great! Thanks for testing/confirming!

Rows
Columns

[GH-ISSUE #7] Failure to open attachments #6