To contribute to an old thread (I'm digging through my postponed-msgs):
On Mon, 19 Nov 2007, Christoph Moench-Tegeder wrote:
> ## Asheesh Laroia ([EMAIL PROTECTED]):
>
>>> That's not possible (at least, not the way you did it). F-spot
>>> references all files by their full paths (there is no easy other,
>>> as perhaps by filename only; some cameras wrap their filenames after
>>> 1000 images, some people use multiple cameras using the same naming
>>> scheme, and so on).
>> inode numbers might be useful as an alternative (as well as obviously useful
>> for finding duplicates that are hard links of each other or duplicates that
>> result from symlink weirdness).
>
> Sounds good, but there are some problems: restoring from backup, or
> moving the photos to a larger disk. It might help for finding hardlinked
> duplicated, but then an "normal user" would not mess with hardlinks in
> his photo collection. So it's perhaps only symlinked directorys, but
> that's wht realpath(3) is for and does not require extra care in case
> of cross-device symlinks.
That's true - inodes are only probably useful if your user ran some
duplicate-file-joining tool.
>> Really, I just wish that the filesystem
>> contained a mapping of sha1_hash=>filename so that F-spot could just ask,
>> "Hey, where'd the file with sha1_hash xxx go?" and get a proper answer.
>
> Even that requires extra care in case you have multiple copies of
> a file.
Presumably you'd get a list of files back from the filesystem / indexing
tool.
Imagine this case:
A user moves a file but doesn't tell a program. The program can't find
the file, and the user doesn't know how to tell the program to update its
big long list of where its data have moved to.
That's pretty normal.
In fact, that's the case that this thread is about. (-:
> For now, I believe that the filename in combination with the "Photos"
> folder is the best solution to that problem. Just tell the user, he
> should always ket the application copy the photos for him and he
> should not mess with his "Photos" folder. Anything else, and he is
> on his own.
Right, sure - my problem is I have so many half-finished imports, or I
import photos but F-spot doesn't delete them from the source, and later I
back up my memory card to some random directory because someone needs to
borrow an SD card....
I look forward to trying the
> Of course you could try sucking all images into a huge database,
> but such a database could be somewhat slow, and in addition you will
> be really screwed if your database gets damaged (a simple directory
> is much more easily recovered).
Sure - what would be nice would be an index of these hashes of the JPEG
photo data. That doesn't change even when the EXIF data does, and lets me
track
In fact, F-spot could store that in its index, and then if I import the
same photo there could be a button that says "Merge with the duplicate
that's already here?" and then it would happily accept the same photo a
second time and just merge any extra metadata into the copy in my F-spot.
-- Asheesh.
--
If you're going to do something tonight that you'll be sorry for tomorrow
morning, sleep late.
-- Henny Youngman
_______________________________________________
F-spot-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/f-spot-list
