Re: F-spot network sync problems

["Olof Sjobergh" <olofsj gmail com>]

Hi again,

Thanks for your reply. I've looked a bit more at it today.

> John is busy refactoring our file handling code to make use of GIO.
> You should be able to patch the tempfile set the correct mtime, but
> make sure you do so against trunk or its all in vain. (Its worth
> checking with John if he has more GIO merges pending, im sure he will
> reply shortly... after waking up). There should be code showing how
> this works in File.py already.
>
> Renaming the temp file is a little trickier, but if you are confident
> you won't encounter name collisons you should be able to do this too.
> Again, im certain an example is in there already.

The methods force_new_mtime and force_new_filename defers the change
for  tempfiles, but then the F-spot importer imports the file before these
deferred changes are applied. As there might be name collisions I
understand this. But could it be possible to create subdirectories in
the tempdir to avoid collisions and be able to rename the files?

Another thing i noticed is that the network sync first copies the file
to a local tempfile named something like "netsyncVDPrxj", and
then this file is copied again to a tempfile "conduitpIXAGs". Is there
a reason for this? Seems a bit unnecessary to me, but I haven't looked
much at the network sync module.

> For the third question, you have no choice but to cook up an f-spot
> patch. The dbus addin maps useful f-spot database model functionality
> to dbus for us to use to sync f-spot, and is available here:
>
> http://svn.gnome.org/svn/f-spot/trunk/extensions/DBusService/
>
> I'm sure you'll be able to figure out what is needed, and that Thomas
> will help you.

I'll try to have a look at this later on.

I was also thinking about adding support for F-spot versions of photos.
It would be nice to have them synced as well. What happens with versions
now? Do they show up as different photos, or is only the latest version
synced?

Best regards,

Olof Sjöbergh