Bug 866489 - Gnome-documents does not actualize path when moving PDF between two tracked folders
Gnome-documents does not actualize path when moving PDF between two tracked f...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-documents (Show other bugs)
7.0
x86_64 Linux
medium Severity medium
: beta
: 7.0
Assigned To: Debarshi Ray
Desktop QE
:
Depends On:
Blocks: 1297830 1313485
  Show dependency treegraph
 
Reported: 2012-10-15 09:41 EDT by Martin Simon
Modified: 2016-11-10 02:08 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-10 02:08:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Simon 2012-10-15 09:41:55 EDT
Description of problem:
If I remove or move PDF file from gnome-documents tracked folder to the untracked one (e.g. ~/myNewUntrackedFolder), the document disappears from gnome-documents - this is right behavior. But when I move the PDF file from one tracked folder to another (same name, just 'mv ~/Downloads/sample.pdf ~/Documents/sample.pdf'), gnome-documents do not handle this and returns path error of this PDF file.

Version-Release number of selected component (if applicable):
gnome-documents-3.6.0-1

How reproducible:
100%

Steps to Reproduce:
1. Download any PDF document (by default to Download folder - this is tracked folder)
2. Move the document to ~/Documents folder (also tracked folder, this is where documents should be)
3. Start gnome-documents and try to open the downloaded PDF document
  
Actual results:
Unable to load "sample" for preview.
Error when getting information for the file '/home/user/Downloads/sample.pdf': No such file or directory

Expected results:
Preview of PDF document

Additional info:
Comment 3 RHEL Product and Program Management 2014-03-22 03:04:58 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 5 Michael Boisvert 2015-05-19 16:41:13 EDT
Able to reproduce issue on gnome-documents-3.14.3-1.el7.x86_64, I can see the old file still with no thumbnail and the new file as well. I feel like after indexing, the moved file will disappear.
Comment 7 Debarshi Ray 2016-06-14 13:32:16 EDT
(In reply to Michael Boisvert from comment #5)
> Able to reproduce issue on gnome-documents-3.14.3-1.el7.x86_64, I can see
> the old file still with no thumbnail and the new file as well. I feel like
> after indexing, the moved file will disappear.

Which version of tracker were you using? I am asking because the bug could have been in tracker too.

Anyway, I can't reproduce this anymore. I tried it on 3 different VMs: RHEL 7.2 Workstation, CentOS 7.2 and Fedora 21, and all of them appear to work as expected.

For reference, I had these versions:
gnome-documents-3.14.3-2.el7.x86_64
tracker-1.2.6-3.el7.x86_64
Comment 8 Debarshi Ray 2016-06-14 13:38:11 EDT
For reference, I was downloading and testing with this PDF:
https://rishi.fedorapeople.org/Fedora_day.pdf

Maybe you have a different PDF and it (likely tracker) is taking longer to handle it?
Comment 9 Debarshi Ray 2016-06-14 14:42:35 EDT
I failed to reproduce this on a RHEL 7.1 VM, which has:
tracker-0.16.2-11.el7.x86_64
gnome-documents-3.8.5-10.el7.x86_64

Out of random curiosity, how much RAM does the VM have? Does it sort itself out if you just wait a bit?
Comment 10 Michael Boisvert 2016-06-14 15:19:31 EDT
Just retested on the newer package that's available on RHEL7.2 and you're right. I can't reproduce this issue even with a large pdf.
Comment 11 Debarshi Ray 2016-06-15 04:59:41 EDT
(In reply to Michael Boisvert from comment #10)
> Just retested on the newer package that's available on RHEL7.2 and you're
> right. I can't reproduce this issue even with a large pdf.

Great. Thanks for trying it out once again, Michael.

We can mark this as something that was fixed by the tracker (bug 1174534) and/or gnome-documents (bug 1174601) rebase in rhel-7.2.
Comment 15 Vera Budikova 2016-09-05 18:57:47 EDT
Verification - OK

Package version: gnome-documents-3.14.3-3.el7.x86_64

Steps to Verify:
1. Download any PDF document (by default to Download folder - this is tracked folder)
2. Move the document to ~/Documents folder (also tracked folder, this is where documents should be)
3. Start gnome-documents and try to open the downloaded PDF document

Results:
Preview of PDF document

Note You need to log in before you can comment on or make changes to this bug.