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 482920 - Adding tags to files corrupts ownership
Adding tags to files corrupts ownership
Status: RESOLVED WONTFIX
Product: f-spot
Classification: Other
Component: Tags
0.4.x
Other All
: Normal normal
: ---
Assigned To: F-spot maintainers
F-spot maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2007-10-03 12:21 UTC by Spook
Modified: 2018-07-01 08:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Spook 2007-10-03 12:21:24 UTC
Please describe the problem:
When I check "write metadata to file", the files are corrupted - or actually the ownership of the files are corrupted. The owner is set to "21". So when an image is tagged, I am no longer allowed to even view the image. And forget about changing the permissons on it! All my images (17.000+) are stored on a FreeNAS server I have set up, as there simply was not enough space on my laptop for them. I am quite impressed with F-Spots performance when handling these files over the LAN, as most of them are 10 megapixel shots. Of course, I could just save the tags locally on my machine, but then I would lose them all if it crashed, or I did a re-install of the system (Ubuntu 7.10). Having to re-tag 17K pictures is NOT my idea of fun, so I really hope your guys can fix this. There are no problemes when writing metadata to local files, it just works.

Steps to reproduce:
1. Set up a network share with some pictures stored in it
2. Tag those pictures and write metadata to the files
3. Access the files outside F-Spot, or just click "edit image" from within F-Spot.


Actual results:
Nothing. Blank image, Nautilus tells me that I am not allowed to even see the image.

Expected results:
It should just work - just as it does with local files on my laptop. 

Does this happen every time?
Every single time, without exception.

Other information:
The share on the FreeNas server I use for storage is connected using CIFS. Performance is great with F-Spot, it took about 30-40 minutes to import (without copying) 17.000+ images. Tried DigiKam also, but it simply choked.
Comment 1 Maxxer 2007-10-03 14:16:27 UTC
I've just tried running a new instance of F-Spot with -b and -p on a Windows share and it worked fine. I've cropped an image and the file was created with the correct permissions and ownership.

How did you copy your pictures to the nas? Manually or by F-Spot import?
Comment 2 Spook 2007-10-03 15:23:15 UTC
First I copied the files manually from my USB2 harddrives to the server share. Then I did an F-Spot import, FROM the share, without copying the photos back to my laptop. What happens when you tag an image (remember to write metadata to file), not just crop it?

What does the -b and -p do?
Comment 3 Maxxer 2007-10-03 18:45:43 UTC
The -b and -p are used to set custom photos.db and Photos directory.

Sorry for the silly question but... If you manually copy a file to the Photos directory on the nas, using the command line or gnome/kde interface, does it get the correct permissions and ownership?
Comment 4 Spook 2007-10-03 19:48:44 UTC
When I manually copy the files, there are no problems what so ever. Thanks for the info on -b and -p - Shold I try setting these options when I start the program?
Comment 5 Maxxer 2007-10-03 21:06:54 UTC
(In reply to comment #4)

> Shold I try setting these options when I start the program?

no, it won't make any change to you. it was just a test.

if it normally works to you, I'm sorry I ran out of ideas. 
Comment 6 Stephane Delcroix 2007-10-07 12:02:31 UTC
*what are your mount options ?
(just type 'mount')

*what are the permissions on the files before tagging ?
ls -l path/to/some/file

*what are the permissions _after_ tagging ?

*what's your session user id (and groups) ? i.e. the user running f-spot
(type 'id')

*what's your umask ?
(type 'umask')

Comment 7 Spook 2007-10-08 07:23:54 UTC
The share is mounted this way:
//192.168.1.250/lager on /media/lager type cifs (rw,mand)

Permissions before tagging:
ssn@ssn-laptop:~$ ls -l /media/lager/Billeder/2004/06-11-2004/img_0559.jpg
-rwxrwxrwx 1 1002 1002 802406 2007-10-02 12:21 /media/lager/Billeder/2004/06-11-2004/img_0559.jpg

Permissions after tagging:
ssn@ssn-laptop:~$ ls -l /media/lager/Billeder/2004/06-11-2004/img_0559.jpg
-rw--w--w- 1 21 1002 802460 2007-10-08 09:21 /media/lager/Billeder/2004/06-11-2004/img_0559.jpg

id and stuff:
ssn@ssn-laptop:~$ id
uid=1000(ssn) gid=1000(ssn) grupper=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),102(netdev),105(scanner),109(lpadmin),115(powerdev),117(admin),1000(ssn)

umask:
ssn@ssn-laptop:~$ umask
0022

Thanks a bundle for your efforts! 

A small translation:
SSN = Me (well, duh)
Lager = Danish word for storage, although the english meaning is much more fun.
Billeder = Danish word for pictures
Grupper = Danish word for groups

Let me know if you need any more info!

Kind regards
Spook/SSN :o)
Comment 8 Stephane Delcroix 2007-10-08 08:16:37 UTC
who's user 1002 on your machine ? and 21 ?
Comment 9 Spook 2007-10-08 09:40:58 UTC
No Idea.

(In reply to comment #8)
> who's user 1002 on your machine ? and 21 ?
> 

Comment 10 André Klapper 2018-07-01 08:51:48 UTC
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010.
Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.