Bug 314340

Summary: Failing to search from NTFS (fuseblk) disk
Product: [Applications] kphotoalbum Reporter: Risto H. Kurppa <risto>
Component: BackendAssignee: KPhotoAlbum Bugs <kphotoalbum-bugs-null>
Status: RESOLVED WORKSFORME    
Severity: normal CC: johannes, null
Priority: NOR    
Version First Reported In: 4.3   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Risto H. Kurppa 2013-02-03 08:46:07 UTC
Kubuntu 12.04.1
KPhotoalbum 4.3.1 from https://launchpad.net/~dominik-stadler/+archive/dsta-precise-ppa/

NTFS-formatted disk, mounted with fuseblk (the default way *buntu mounts these)
/dev/sdb1 on /media/VERBATIM type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)

Creating database there works, index files are generated as expected.
But when I tell KPA to scan for new images, nothing happens. Nothing. No scanning, no images found, no messages. The disk has about 1T of data, plenty of photos there.

Pointing to vfat USB flash seems to work, scans for new images as expected

Can the mount type be a problem?

Next step: Create a NTFS usb flash, copy images there and try to scan..
Comment 1 Risto H. Kurppa 2013-02-03 21:02:33 UTC
I formatted a 8G USB flash to NTFS
/dev/sdd1 on /media/2E3F7C655080A3F6 type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)

And it works.

This time I'm on a different computer, running Kubuntu 12.04.1 too, but KPhotoalbum compiled from GIT HEAD sources less than a week ago..

Any ideas how to debug the 'scanning fails with no trails' thing..?
Comment 2 Jan Kundrát 2013-02-04 14:05:13 UTC
(In reply to comment #0)
> But when I tell KPA to scan for new images, nothing happens. Nothing. No
> scanning, no images found, no messages.

Running under strace might answer what is wrong. To see just the file IO, use `strace -e trace=file -p $PID` where $PID is the PID of the running KPA instance.
Comment 3 Risto H. Kurppa 2013-02-08 21:14:36 UTC
Trying  strace -e trace=file -p PID

Scan succeeded when pointing to a single 132M subdir of that disk but at least the root fails. The 'main data directory' on the disk about 1T, does it make a difference?

Based on the log, it first scans the .Trash-1000 -folder, finds the files there.

stat("/media/VERBATIM/.Trash-1000/files/Aapo/P1120171.JPG", {st_mode=S_IFREG|0600, st_size=4262439, ...}) = 0
stat("/media/VERBATIM/.Trash-1000/files/Aapo/P1120171.JPG", {st_mode=S_IFREG|0600, st_size=4262439, ...}) = 0
access("/media/VERBATIM/.Trash-1000/files/Aapo/P1120172.JPG", R_OK) = 0
stat("/media/VERBATIM/.Trash-1000/files/Aapo/P1120172.JPG", {st_mode=S_IFREG|0600, st_size=2031536, ...}) = 0

Then at some point it starts to scan the normal directories:
access("/media/VERBATIM/Vanhat HDDt/HDD12_IBM60_editkoneen_toinen_levy/Datat/EOK data1/IOmega ZIPit/ZIP 01/MB ABS ongelmat/MVC00401.JPG", R_OK) = 0
stat("/media/VERBATIM/Vanhat HDDt/HDD12_IBM60_editkoneen_toinen_levy/Datat/EOK data1/IOmega ZIPit/ZIP 01/MB ABS ongelmat/MVC00401.JPG", {st_mode=S_IFREG|0600, st_size=168396, ...}) = 0
stat("/media/VERBATIM/Vanhat HDDt/HDD12_IBM60_editkoneen_toinen_levy/Datat/EOK data1/IOmega ZIPit/ZIP 01/MB ABS ongelmat/MVC00401.JPG", {st_mode=S_IFREG|0600, st_size=168396, ...}) = 0
access("/media/VERBATIM/Vanhat HDDt/HDD12_IBM60_editkoneen_toinen_levy/Datat/EOK data1/IOmega ZIPit/ZIP 01/MB ABS ongelmat/MVC00402.JPG", R_OK) = 0
stat("/media/VERBATIM/Vanhat HDDt/HDD12_IBM60_editkoneen_toinen_levy/Datat/EOK data1/IOmega ZIPit/ZIP 01/MB ABS ongelmat/MVC00402.JPG", {st_mode=S_IFREG|0600, st_size=192525, ...}) = 0


Anything here that rings a bell? 



Any pointers what to do next?
Comment 4 Johannes Zarl-Zierl 2013-02-08 22:51:48 UTC
Just guessing wildly:

What exclude directories do you have set?
# grep excludeDirectories ~/.kde/share/config/kphotoalbumrc

Did you try with the exact same data on the different file systems?
Comment 5 Risto H. Kurppa 2013-02-09 07:11:02 UTC
ok@ubuntu:~$ grep excludeDirectories ~/.kde/share/config/kphotoalbumrc
ok@ubuntu:~$ 

I clean the kphotoalbumrc always before running these tests

Can't copy the data to another disk.. 1.7T now. This is a disk where X harddrives have been copied to merge/clean/find duplicates etc
Comment 6 Andrew Crouthamel 2018-11-09 01:09:56 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Andrew Crouthamel 2018-11-20 04:07:35 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand.

Thank you for helping us make KDE software even better for everyone!
Comment 8 Johannes Zarl-Zierl 2021-01-27 22:40:11 UTC
Hi Risto,

I just tried again to reproduce the bug, but to no avail: I created a database in the root directory of an NTFS-formatted USB disk that was mounted via fuseblk. 
Finding new images did work with, just as with your USB stick.

I guess you either have a workaround by now or you gave up on kphotoalbum altogether (I hope it's not the latter).

If you have no objections, I am closing this bug.

  Johannes