| Summary: | Failing to search from NTFS (fuseblk) disk | ||
|---|---|---|---|
| Product: | [Applications] kphotoalbum | Reporter: | Risto H. Kurppa <risto> |
| Component: | Backend | Assignee: | 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
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..? (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. 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?
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? 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 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! 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! 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 |