After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 517626 - Not all images imported
Not all images imported
Status: RESOLVED DUPLICATE of bug 517234
Product: f-spot
Classification: Other
Component: Import
0.4.x
Other All
: Normal normal
: ---
Assigned To: F-spot maintainers
F-spot maintainers
Depends on:
Blocks:
 
 
Reported: 2008-02-20 10:28 UTC by Alexander Skwar
Modified: 2008-02-20 15:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alexander Skwar 2008-02-20 10:28:14 UTC
Please describe the problem:
I re-imported my directory where I stored all of my pictures. The import dialog shows, that 5744 images are to be imported.

In the directory, there are more files than this. I'll attach (or make available) a file listing of the directory.

Steps to reproduce:
1. rm ~/.gnome2/photos.db
2. wget -O - http://public-files.askwar.s3.amazonaws.com/f-spot/photos.db.dump.sql.gz | sqlite3 ~/.gnome2/photos.db
3. mkdir -p "/home/askwar/Desktop/My Pictures/Photos"
4. wget -O - http://public-files.askwar.s3.amazonaws.com/f-spot/Kategorien.tar.gz | tar xvjf - -C "/home/askwar/Desktop/My Pictures/Photos"
5. Start f-spot
6. "Re-"import the directory "/home/askwar/Desktop/My Pictures/Photos/Kategorien"

Actual results:
F-spot will show, that there are 5744 images to be imported. But there are more images than that in the directory structure under "Kategorien".

Expected results:
All images should be re-imported, ie. there should be about 6609 images.

Does this happen every time?
Yes.

Other information:
The TAR at http://public-files.askwar.s3.amazonaws.com/f-spot/Kategorien.tar.gz contains a TAR archive of all of my pictures. It's a "fake", in so far, as there's just 1 file in the TAR with 6852 hard links. Because of that, the TAR isn't big - it's just 508940 bytes. Uncompressed, it needs about 1.4M on a ext3 filesystem.
Comment 1 Alexander Skwar 2008-02-20 10:42:01 UTC
When I rm ~/.gnome2/f-spot/photos.db and then try to import that directory structure (ie. with a newly created photos.db), f-spot would import 6621 images.

I'd expect to see this number as well, when I try to re-import the directory with my already exisiting photos.db.
Comment 2 Alexander Skwar 2008-02-20 11:06:41 UTC
- When you try to do the import of Kategorien.tar.gz (or rather the file(s) in that directory), there'll be 2 import errors, because I saved a JPEG file as a tif and as a GIF. Simply disregard those errors.

- When you have f-spot create a new, blank photos.db, it'll offer to import 6621 images. Do that import. And then, right when that import has finished, try to the import again - f-spot now offers to import just 5815 images.

- I always *uncheck* that pictures are to be copied to the Photos folder. They should stay where they are.
Comment 3 Stephane Delcroix 2008-02-20 14:17:46 UTC
(In reply to comment #0)
> Expected results:
> All images should be re-imported, ie. there should be about 6609 images.

in fact, no. F-spot shouldn't reimport anything, or they'll and up as duplicates.

So, there's probably a bug in the duplicate check with filename with blanks or special characters.

Next time, please narrow down your test case and you'll find the bug origin by yourself.
Comment 4 Alexander Skwar 2008-02-20 14:49:35 UTC
(In reply to comment #3)
> (In reply to comment #0)
> > Expected results:
> > All images should be re-imported, ie. there should be about 6609 images.
> 
> in fact, no. F-spot shouldn't reimport anything, or they'll and up as
> duplicates.

Hm?

Existing files should not be re-imported? So Bug 169646 is closed (at least as far as that's concerned)?

> So, there's probably a bug in the duplicate check with filename with blanks or
> special characters.

That would be a regression. So my comment in Bug 517234 was right - it used to be different. It used to be so, that f-spot would not create duplicates. This must have been in 0.3.5.

> Next time, please narrow down your test case and you'll find the bug origin by
> yourself.

Well, I reported Bug 517234. This was duped to Bug 169646 which, as of right now, is still open. So I supposed that the expected behaviour of f-spot would be, that duplicates are created (as Bug 169646 is not fixed yet).
Comment 5 Stephane Delcroix 2008-02-20 15:03:26 UTC
You're right, bug #517234 is not a dup of bug #169646.
This one is a dup of bug #517234 though...

bug #169646 is about /smartly/ handle duplicates coming from cameras or being renamed...

anyway, I now have a patch for this bug, err... for bug #517234.

*** This bug has been marked as a duplicate of 517234 ***