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 325381 - no way to archive (backup) photos
no way to archive (backup) photos
Status: RESOLVED WONTFIX
Product: f-spot
Classification: Other
Component: General
WISHLIST
Other All
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
gnome[unmaintained]
: 329034 354847 413075 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-12-31 16:16 UTC by Danielle Madeley
Modified: 2018-07-12 00:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A script to scale pictures (1.45 KB, text/plain)
2006-09-11 12:38 UTC, c. Heppner
Details

Description Danielle Madeley 2005-12-31 16:16:41 UTC
Every year, I archive each of my main directories my taking their contents and moving it to a 200x directory and removing the write bit, eg.

$ cd Photos
$ mkdir 2005
$ mv * 2005
$ chmod a-w 2005

Of course, if I do this, then F-Spot will lose all of my photos, and if I reimport them I'll lose my metadata. Neither of these things do I want.

It would be nice to take an entire set of photos (say selectable by date range) and archive them. In retrospect, I should have just started by putting them in a 2005 directory to begin with (hindsight is 20x20 and all that). So if this is a WONTFIX, I am willing to accept a hacky, dodgy method to change the locations of the files in the database.
Comment 1 Bengt Thuree 2006-01-29 04:44:17 UTC
I just added another bug which is a bit similar to this one.
http://bugzilla.gnome.org/show_bug.cgi?id=329034
Comment 2 Bengt Thuree 2006-01-29 04:46:35 UTC
I added my text from bugg http://bugzilla.gnome.org/show_bug.cgi?id=329034 since the current one is oldest.
==========================

Since we all are now getting bigger and bigger digital photoalbums, I am sure
that there is a need for a simplified backup process for these photos.

F-Spot could assist with this, by having an extra (hidden?) tag per photo
stating when this picture was last backuped.

For instance. By default the "backup druid" is activated (configurabled since
some want to backup the files by other means), and will remind every now and
then (configurable) of long time since last backup and now there are XXXX
pictures that have not been backuped to secondary medium.

Perhaps it could be possible to specify two different backup mediums?
1) Medium 1 (hard drive/directory for instance) - Every XX days
2) Medium 2 (External CD/DVD/Tape/Hard drive)   - Every YY days

Possible to specify if you want to backup only original, original + default, or
all versions.

Different backup options.
1) Simple cp/tar or something with checksums
2) Using optional dedicated backup software (which should be detected)

Should be possible to select which pictures to backup, or all not backuped
pictures. Should be possible to force F-Spot to think all pictures have been
backuped. (After a restore, or some photos have already been backuped by other
means)
Comment 3 Gabriel Burt 2006-01-29 05:12:46 UTC
*** Bug 329034 has been marked as a duplicate of this bug. ***
Comment 4 Bengt Thuree 2006-02-06 10:35:41 UTC
Just a small comment for Davyd, enhancement bug 302566 and its associated patch allows you to rename (and move) the photo, and automatically create a YYYY/MM/DD directory structure for you if you want.
Comment 5 Alexander van Loon 2006-05-09 07:55:12 UTC
I agree, I was just about to file a feature request for this as well, but then I found this bug.

All I'd like to see is a simple option which would allow you to backup tags data. Currently I just copy my entire Photos dir when I want to backup, but then I lose my tags data. I have no idea were the tags data file is located.
Comment 6 Bengt Thuree 2006-05-09 08:05:35 UTC
The tags data file (in SQLite format, and contains some other fields apart from Tags as well) is in ~/.gnome2/f-spot/photodb 
if I do not remember wrong...
Comment 7 Alexander van Loon 2006-05-09 08:32:04 UTC
Ok, thanks for the information, I'll use that for backups as well then as long this feature isn't implemented yet.
Comment 8 Bengt Thuree 2006-06-06 01:03:01 UTC
Modifying title a bit
Comment 9 Gad Kadosh 2006-08-20 06:46:54 UTC
As a user I would want to be able to backup some collections of pictures into say a CD or DVD, with the all the related data/metadata mentioned already. What should be addressed is that I could do the backup for safety reasons (meaning I keep the pictures in my main library too), but I could also do the backup for space-saving reasons (meaning the pictures will then be removed from the main library, i.e. my laptop's small HD). In the latter case how does f-spot deal with it. Maybe it should be possible to keep only thumbnails or small versions of the pictures in the main library plus the information about where the originals should be found - and then when you want to watch a particular picture f-spot asks you to insert the CD/DVD or connect the backup driver etc...
Does that sound reasonable/possible?
This is just a braindump based on my need to transfer pictures from my hard drive to a CD/DVD and still be able to easily access them from f-spot whenever I want (as well as access them independently of f-spot with other software/other computer or standalone machine...)
Comment 10 Gabriel Burt 2006-09-08 18:51:42 UTC
*** Bug 354847 has been marked as a duplicate of this bug. ***
Comment 11 c. Heppner 2006-09-11 12:38:01 UTC
Created attachment 72548 [details]
A script to scale pictures
Comment 12 c. Heppner 2006-09-11 12:38:41 UTC
I've been doing a little python script that does the following:

Go through directory B and sub directorys and downscale all images that are also in directory A.

So you can:
1. Export a bunch of images to a directory
2. Mark those images with a new Tag 'Archieved on cd xyz'
3. Run the script with 'backupPhotos exportdir f-spot-dir'

So you'll have the high-quality photos in the export dir and some little pictures (150px hardcoded in the script) in the f-spot dir.

This is quite usefull for me. Maybe I'll add automatic-tagging support (than you do not have to tag manually).

The script uses python2.4 and ImageMagick.
Known Bugs: Two pictures are called 'the same' when they have the same filename.
No warranty.
Comment 13 Antony Mee 2006-09-19 08:45:53 UTC
This has become more of an RFC... So please do :-)

c. Heppner's idea seems like a bright one and is precisly the kind of thing I came here looking for.  Good archiving abilities would really make f-spot stand out in the crowd.

There appears to be some confusion above about backup and archiving.  Backups of both photos and photo metadata should work just fine using your favourite backup tool.   (Provided both your Photos directory and .gnome2 directory are suitably backed up)

Archival is a different concept and certainly requires some F-Spot awareness.  I really like c. Heppner's idea that thumbnails are kept around so you still have a visual reminder that the photos exist.  But perhaps it is better that f-spot manages thumbnails for all images itself... And perhaps it only needs one thumbnail of the "latest" or "default" version of any particular image but I think the above script will create thumbnails of everything.

The behaviour I would like to see is some kind of tagging for archival and then an action to archive all tagged files. Perhaps a "There are "more than some user set limit" MBs of photos tagged for archival.  Would you like to write these to archive media now?".  The software and I should somehow should a name that I should write on the CD or other media to identify it.

The images should, once archived, still appear in the metadata (either with or without a thumbnail (user preference?)) and thus be browsable in f-spot.  If I select an archived image I should be prompted with something like:
  "This image is archived on:
      'Media set XXXX', '2005 archive XXXX CD', and ....
   If you would like to view or revive the file please insert one of those   
   disks in the appropriate drive.

   <Revive>  <View from archive> <Cancel> "

By revive (please give me a better word if you have it) I mean the system will go get the files from the archive media and restore them on my local hard drive.  They will not be removed from the archive, and will be considered read-only on my local system and wil not be flagged as "to archive".  I may for example wish to work considereably with and archived photo set and so choose to revive the whole lot.

From these read only images I should be able under the existing system to create new modified versions which themselves could be archived. Moreover, I should be able to tag photos (or versions of photos) that have previously been archived for archival once more.  They could then exists one more than set of archive media and the f-spot metadata will keep a list of locations.  (Hence the multiple choices in the revive prompt described earlier)

Ideally, sufficient f-spot metat data (perhaps the whole database but with minimal thumbnails) should be written to all archive media.  This then allows the archive media to for example be imported into an f-spot session on another system with full metadata, or indeed be used as a form of f-spot specific backup.

While these plans might sound grand, there may be a simple way to make all this happen with minimal work on f-spot.  What do people think of FUSE (filesystemes in user space - http://fuse.sourceforge.net/)?  I have used them for several applications now and the system seems pretty stable now.  One in particular of interest here is the hierfs -- http://hierfs.sourceforge.net/ .  That project implements precisely a quite general archive file system. So...

Imagine a hierfs filesystem mounted as "~/Photos/Archive" or something.  To archive a set of photos, all f-spot must do is move them to create a subdirectory corresponding to the name of the media set, and then copy the necessary files (probably with full date paths) to that sub directory, and update it's meta data.  f-spot would still need to have to be aware of the concept of "archived" files... Perhaps simply by looking at their path? And there would need to be multiple locations for multiply archived (and possibly revived) photos.  For example a photo called IMG0000.JPG might exist as:

   ~/Photos/2007/01/04/IMG0000.JPG
to archive it to my "2007 archive" f-spot would move it to
   ~/Photos/Archive/2007 archive/2007/01/04/IMG0000.JPG
(perhaps use the md5 or url encoded archive name?)
It should also keep a thumbnail on the local filesystem if such a preference is set.

FUSE handles the 'nasty' bit... It will gather up files in a temporary location (a bit like when you copy files to CD in Windows)  and allows you to transfer them to removable media (perhaps even making multiple copies) and removing the original files from the system.  When a program like f-spoty tries to access ~/Photos/Archive/2007 archive/2007/01/04/IMG0000.JPG hierfs, which keeps it's own database, will prompt for the appropriate media.

Simply copying/mirroring or maybe linking the f-spot photodb (+ timestamp/version info?) to the hierfs directory might be sufficient to perform a selective recovery of photos from an archive.

I doubt giving f-spot the ability to initiate certain functions like writing any outstanding media would not be very difficult.

One could maybe take heirfs and make a specific "f-spot archive fs" of some sort from it.

Comment 14 Jason.Dwyer 2007-10-11 11:55:41 UTC
Has there been any movement on archiving? 

antony's comment #13 is pretty much the thing i'm looking for, but it looks like its about a year old now.

i've been running low on disk recently, and a quick $>du -sh ~/Photos shows where all my space is going ( new cam and fast 4GB card and phwooor... )

i guess i could get a little more ruthless with what is 'acceptable' focus, but i'd rather have a neat way of getting f-spot to know about an image, but have it archived to removable/portable/network media - allowing me to still flick through thumbnails and prompting for the archive media should i want to see the full image.

Comment 15 trendleforum 2008-02-27 20:51:52 UTC
In my Windows days I bought Photoshop Album specifically because it had a good archiving feature (IMHO).  I think that it is an essential feature for any worthwhile Photo Management tool. I've spent hours trying to recover photos off a crashed MS system (ok that might be dealt with by backups too).

So please.... do make an archiving feature a priority over 'nice to have' features.

One of the photoshop Album features that was nice was the ability to retain small images of photos that had been 'archived' off the principal system.  These photos keep a tag of where the real location of the archived photo is and prompts for that CD (if that's where it was archived to) when you wish to use the fullsize image.

It seems that C Heppners script goes some way to achieving this (thanks for sharing) and A Mee's notes are also on track too.

My question would be ... Does F-spot have enough 'hooks' to allow interaction with an 'archiving' plugin ?   How would that work ? 
Then perhaps we could get different feature sets for archiving without interfering with the F-Spot code directly.  It shouldn't be necessary to re-invent an archive tool just for F-spot.
Comment 16 Jörg Rosenkranz 2008-05-20 14:28:56 UTC
This is also my most wanted feature. Space on a laptop is limited and it would be very usefull to put some older/not changed/not often viewed images in their original resolutions to external space. This could be an USB or network drive.
Comment 17 Maxxer 2008-09-02 08:08:04 UTC
*** Bug 413075 has been marked as a duplicate of this bug. ***
Comment 18 abe 2009-11-08 00:27:09 UTC
In my dream-list too!
I add only a suggestion:
when you archive a set of photo, f-spot should save photos data (tags and comments) in the same place, e.g. in an XML file. In the case of a drive failure (or more simply, if you want to move your photos from a computer to another), you wont need to re-insert everything.
Comment 19 André Klapper 2018-07-12 00:09:47 UTC
F-Spot has moved to https://github.com/f-spot/f-spot/issues

If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub.

Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.