Library directory can become "unset" causing Hardware Error during import
Submitted by Jim Nelson
Link to original bug (#718734)
Description
---- Reported by jim@yorba.org 2012-11-28 16:31:00 -0800 ----
Original Redmine bug id: 6108
Original URL: http://redmine.yorba.org/issues/6108
Searchable id: yorba-bug-6108
Original author: Jim Nelson
Original description:
Reported by one of our users: http://lists.yorba.org/pipermail/shotwell/2012-November/004398.html
It appears the library directory became unset (directory was deleted?) causing import to fail when photos are to be copied in.
Related issues:
- related to shotwell - 6241: Trashing the last image in a library, then expunging the ... (Fixed)
- related to shotwell - 5027: [norepro] user can't change library location (Invalid)
- related to shotwell - 6722: Library directory can be set to subdirectory during import (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:33:00 -0700 ----
History
Comment 1
Updated by Jim Nelson 12 months ago
The user later reported that this error occurred prior to a hard drive failure. We should still try and reproduce the problem using my suggested steps above. If we can't reproduce, we'll close as Invalid.
Comment 2
Updated by Joe Bylund 12 months ago
I determined this is caused by two possible bugs, or at least confusing behaviors.
- Insufficient write permissions to library directory are reported as a hardware error:
Steps to reproduce:
With a directory structure of YYYY/MM/DD make sure user running shotwell does not have write permissions to at least one folder and then import a picture which should be placed in that folder.
Observed behavior:
Error message reporting hardware error.
Expected behavior:
Error message reporting insufficient permissions on library directory.
- Difficulty setting library/import directory. When I try to set
/media/244d2c6e-62f2-4a/Pictures/Photos
as my import directory and it contains only a single subdirectory "2012", the library directory seems to be set to
/media/244d2c6e-62f2-4a/Pictures/Photos/2012
I think I've found a workaround which is to create another empty directory in the Photos directory.
Sidenote: it was another user who reported having a similar issue before a hard disk failure.
Edit: I had reversed the expected and observed behaviors.
Comment 3
Updated by Jim Nelson 12 months ago
Thanks for passing this on, Joseph, this'll help when we attack the problem.
Regarding your second use case, that might be a product of the GTK File Chooser dialog, which can be a little confusing to use when selecting a directory. (The control is used to choose files and directories.) Could you try again and let us know what steps you're using to reproduce this?
Comment 4
Updated by Jim Nelson 11 months ago
- Category set to ux
Comment 5
Updated by Jim Nelson 9 months ago
- Assignee set to Clinton Rogers
Comment 6
Updated by Clinton Rogers 9 months ago
- % Done changed from 0 to 10
Comment 7
Updated by Clinton Rogers 9 months ago
- % Done changed from 10 to 20
The first problem Mr. Bylund notes below should be either fully handled or greatly improved by #5786, especially when combined with the import logging feature...
As for how it becomes unset in the first place, this is still being researched; in times past, there was at least one bug where the user's library directory could be deleted without user intervention, so maybe it's a variation of this.
Comment 8
Updated by Clinton Rogers 9 months ago
Aside from weirdness with the file chooser, it's been discovered that manually renaming one's library directory while the application is running will cause the directory path to become unset as well.
Comment 9
Updated by Jim Nelson 9 months ago
- Category changed from ux to library-mode
Comment 10
Updated by Clinton Rogers 9 months ago
- Status changed from Open to Blocked
-
Assignee deleted (
<strike>
_Clinton Rogers_</strike>
)
After looking at this in-depth, I am unable to figure out how to reproduce this. The user experience should improve quite a bit with better error reporting, and at least one library-directory-killing bug fixed, but I strongly suspect we won't be able to catch every case of this until we get steps on how to trigger it (or #5027 (closed), which I have a hunch is related).
Comment 11
Updated by Clinton Rogers 8 months ago
- Status changed from Blocked to Open
- Assignee set to Clinton Rogers
- Priority changed from High to Urgent
- % Done changed from 20 to 10
Comment 12
Updated by Clinton Rogers 8 months ago
It looks like https://bugzilla.gnome.org/show_bug.cgi?id=570803 could be the root cause of all this woe, although there may be another bug that is closer temporally and more appropriate (this will be linked as soon as its found).
It looks like (to the unpracticed eye), we're getting here: https://git.gnom e.org/browse/gtk+/tree/gtk/gtkfilechooserbutton.c?id=67f5e595a796a8321d6dc7737 c58476564998c07#n2646 ...
Comment 13
Updated by Jim Nelson 8 months ago
-
Assignee deleted (
<strike>
_Clinton Rogers_</strike>
) - Target version changed from 0.14.0 to 0.15.0
Comment 14
Updated by Joe Bylund 8 months ago
This is the simplest way I could reproduce:
mkdir /.shotwell_testing
mkdir ~/Desktop/shotwell_testing_lib
shotwell --no-runtime-monitoring --datadir=/.shotwell_testing # I don't think the no runtime monitoring is necessary
then set your import directory in shotwell to ~/Desktop/shotwell_testing_lib
then import two photos, one from 2013 and one from 2012
then go back to preferences and see that the directory is displayed as "(none)" (I think it is still importing to the correct directory at this point though), then if you use the dropdown and select other because of the way autocomplete works there it will set the import directory to ~/Desktop/shotwell_testing_lib/201 which does not exist, and then if you import another picture it will drop it inside ~/Desktop/shotwell_testing_lib/201/YYYY/MM/DD
Comment 15
Updated by Jim Nelson 8 months ago
Thanks for the repro steps, Joe! I went through this myself and was able to reproduce something like what's been reported earlier. In the console log, this is what was written:
L 4723 2013-04-01 11:43:39 [DBG] BatchImport.vala:1937: Importing /home/jim/Desktop/shotwell_testing_lib/2009/2010/06/04/IMG_8723.JPG
L 4723 2013-04-01 11:43:39 [DBG] BatchImport.vala:1937: Importing /home/jim/Desktop/shotwell_testing_lib/2009/2009/02/24/IMG_0600.JPG
Note the extra 2009 in the path, and indeed, that's where they're written. In addition, the import directory was then set to the first 2009 in the path, although I'd never set it to that with the Preferences dialog.
However, when I reset everything and went back to reproduce the steps again, I couldn't. It appears there was some step in there that caused this to happen. Further experimentation is important (for example, some combination of steps using "in place" versus "copy files" importing).
More important, however, is that all files imported successfully, whereas this ticket is about photos not importing due to a library directory failure. If I can reproduce the problem I'm describing here (or you can as well, Joe) we need to file it as a separate bug.
Comment 16
Updated by Jim Nelson 8 months ago
- Priority changed from Urgent to High
Downgrading to High, as we've had a tremendous problem reproducing this and not had any other reports of it.
Comment 17
Updated by Joe Bylund 8 months ago
What I saw when I reported this to the list was that the files did not import and the directory became unset or "(none)". I assumed they were related, but later found that the failure to import was due to a permissions issue (unrelated to the library directory not displaying correctly and being changed). So maybe this bug should be closed and a new one opened for the directory weirdness or this one retitled.
Also, of note to other users you can workaround this bug by putting an extra directory in your library folder which does not share a leading character with at least one other folder in the library folder (don't know if hidden folders work).
Comment 18
Updated by Jim Nelson 8 months ago
I'm considering marking this as closed, since it's been so difficult to reproduce. Since we've seen the other library problem recently (as in, today), it does deserve its own ticket: #6722.
I think I'd like to leave this open until #6722 is understood. That might offer a glimpse into why this situation ever occurred, assuming it's related to the library directory being unset (versus a filesystem issue).
Comment 19
Updated by Jim Nelson 6 months ago
-
Target version deleted (
<strike>
_0.15.0_</strike>
)
--- Bug imported by chaz@yorba.org 2013-11-25 21:58 UTC ---
This bug was previously known as bug 6108 at http://redmine.yorba.org/show_bug.cgi?id=6108
Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution