Email attachment - opening attachment display "inode error"

damoleon · 12 February 2021 10:03

REPRODUCIBILITY (% or how often): Happened once
BUILD ID = OS VERSION (Settings > About product): KOLI 4.0.1
HARDWARE (XA2, Xperia 10…): Xperia
UI LANGUAGE: English
REGRESSION: (compared to previous public release: Yes, No, ?):

DESCRIPTION:

When clicking on the attachement (.jpg)in a email, it opens in the gallery but a message says “File type ‘inode/directory’ is not supported”

PRECONDITIONS:

STEPS TO REPRODUCE:

open an email with attachment
click on the .jpg attached

EXPECTED RESULT:

show in gallery without any particular message

ACTUAL RESULT:

show in Gallery but display an error message

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)

skanky · 27 October 2021 15:36

Happens for pdfs too. Usually the first attachment will open, but none of the subsequent ones.

EDIT clarification: When I said first, I meant the first one opened, not necessarily the first one in the list. If I have say two attachments, then I can open either one, but if I try and open the other, I get the error message. This is the case for any number of attachments.

So the workaround is to open one attachment, close the email app, reopen it, open the next attachment, etc.

jovirkku · 29 October 2021 12:31

Thanks for reporting.
I am able to reproduce this on the upcoming 4.3.0 release (sigh…), too. That is, I can see the error message "File type ‘inode/directory’ " and the related attachment does not open with the 1st tap. However, I am able to open the attachment by tapping it again. Hence there is no need to restart the Email app. As soon as I have opened all attachments, there is no problem (and no error) opening them again.

==> bug filed.

JoOppen · 29 October 2021 15:20

Indeed, there is no problem to re-open mutiple attachments once they were downloaded on the device, i.e. after the first opening/viewing of the attachments. Therefore the bug may be related to the way how the attachements are downloaded or stored, respectively.

skanky · 17 November 2021 14:34

Thanks for the updae and reply (sorry for my late response).

I’ve just checked and the re-tap doesn’t work for me. I can only open the attachements (after opening the ‘first’) after restarting the email app. This is under the latest (4.3.0.12) version. So the bug does seem to be different between our devices, for some reason.

On the other aspect, I get the same behavior. That is, once an attachment has been downloaded, it can be opened, even if another one has been downloaded and opened.

peterleinchen · 17 November 2021 19:24

Happened to me for rpm file type as well (on 4.3.0).

Raymaen · 27 December 2021 07:52

I have the same Issue. When getting more than one attachment opening the first one works fine. but when opening the second an error appears. only by leaving the current Email and moving to inbox overview and reopening the e-Mail I am able to open the second attachment, but then again error when trying to open the third. so again leaving the email and reopening it again…

(4.3 on Xperia 10 II)

dcaliste · 6 January 2022 14:27

I’m proposing a fix for this bug, see:

github.com/sailfishos/nemo-qml-plugin-email

[nemo-qml-plugin-email] Don't set URL in attachment list model if the…

sailfishos:master ← dcaliste:inode

opened 02:26PM - 06 Jan 22 UTC

dcaliste

+10 -8

… file does not exist. @pvuorela, I'm trying to solve https://forum.sailfisho…s.org/t/email-attachment-opening-attachment-display-inode-error/4805/6 The reproducer is the following: - use POP - get an email with at least two attached files - tap on the first one : it is opened - tap on the second, a banner will complain about the impossibility to open inode mime type and bug path is: - in attachmentlistmodel, after the first file has been copied from QMF internal storage to the file structure in Download, the `QFileSystemWatcher` callback line 298 in triggered. But for other attachment, the files have not been copied yet. So `attachmentPath()` is return an empty string, - then `onAttachmentPathChanged()` is creating an URL with just the directory. I think the `onAttachmentPathChanged()` should not mangle the path. It is called from the email agent that is getting the path from QMF only and thus guaranteed to be valid. The fact that we are using this callback by hand in the file watcher with a wrong path is the problem. The PR here is fixing the problem, but I would consider two better possibilities for medium term : - get the filename for a part directly from QMF instead of mimicking its behaviour with `.remove('/')` statements, - remove the directory watcher completely, since the email agent will signal anyway when a file has been downloaded and copied to a valid URL.