Document Viewer (propably) create files in ~Documents

[Krzysztof Tataradziński]

Steps to reproduce bug:

Download xyz.pdf file via web browser and select to open it by Document Viewer.
Download xyz.pdf (it will create file xyz (copy 1).pdf) again via web browser and select to open it by Document Viewer.
In Document Viewer now we've got two files - xyz.pdf and xyz (copy 1).pdf.
Open File Manager and go to ~Documents. We we list of two files xyz.pdf and xyz (copy 1).pdf.
Use File Manager to delete xyz (copy 1).pdf. Of couse file disappear.
Go back to Document Viewer and we see still two files xyz.pdf and xyz (copy 1).pdf. Open xyz (copy 1).pdf.
In FIle Manager file xyz (copy 1).pdf will appear again.

[Pat McGowan (pat-mcgowan)]

Is the bug is that the doc viewer doesn't detect the file has been removed?

[Stefano Verzegnassi (verzegnassi-stefano)]

Hi,

I'm sorry for the late reply, but I've been notified about this just yesterday.

Yes, Document Viewer has an AppArmor exception and it's able to save files in "~/Documents".
However, I'm not able to reproduce the bug (on the latest version of DocViewer available in the Ubuntu Store).

I've googled for some PDF document, and downloaded it twice.
As I delete the second copy of the file through File Manager, also the second entry in Document Viewer disappears.

It may happens (and indeed it used to do) that the entry in Document Viewer is not removed, since the code that handles the documents list is not solid enough yet.

However it sounds very strange to me that DocViewer re-creates the second copy of the file, since there's no code that could do that (Content import/download is only single-shot, when the user explicitely requires that action).

Therefore I have to mark this report as incomplete.
I need some extra info in order to understand which could be the reason of the issue.

Which is the size of the PDF document?
If you can reproduce this bug again, can you confirm that the file is properly removed by File Manager (e.g. connecting your phone to the PC)?

Thanks again for taking the time to report this bug and helping us to improve this application.
I'm looking forward to your reply.

[Krzysztof Tataradziński (ktatar156)]

It was only one time error, I can't reproduce it now :/ So maybe we should delete that bug? When that bug will again appear I will try to provide as much info as I can.

[Stefano Verzegnassi (verzegnassi-stefano)]

I think that the bug currently exists, and it probably due to the app cycle policy.

When an application is not the top-most window on screen, all its activities are temporarily paused.
This could have stopped the deletion of the file (in File Manager) or the file system watching (in Document Viewer).

Indeed in Document Viewer we don't fully track yet all the changes that may have occured when the app was suspended.

I keep this report as "incomplete". IIRC that means that it doesn't expire for 180 days since the last activity. I'll have a deeper look at it during this time, since we've already scheduled a review of the code that handles the list of available documents.
Title, status or the description of the issue will be updated as further informations will be available.

Thanks again for pointing out this issue. We will consider this discussion when we'll redesign the "faulty" components.