(In reply to comment #0)
> Please describe the problem:
> Numerous bug reports have been submitted about Rhythmbox's handling of ID3
> tags, so it is clear that its ID3 support is (yet) less than perfect. I still
> like RB as a player, though. To avoid it corrupting my tags..

> .. (and, I might add, somewhat corrupted).

Just as a matter of form, please leave exposition like this out of bug reports; it's not relevant to the bug at hand, gives no useful information, and mostly serves to annoy people.

I can reproduce this on Ubuntu 8.10 with Rhythmbox 0.11.5.

I think I've experienced nearly the same issue: At my home, we share a computer and put all the ripped music files in a shared folder with appropriate permissions and umask:

- shared directory and files are of group "users", all users needing to write are members of that group
- umask 0002
- permissions on directories u=rwx,g=rwxs,o=rx (02775), on files ug=rw,o=r (0664)

After editing a tag on a file which originally belonged to my wife, it belonged to me (that is expected), but its permissions are u=rw,go= (0600), meaning my wife can't play it anymore. I know I could go on the command line and fix the permissions afterwards, but this doesn't feel right ;-).

Is there anything else you need to work on this bug?

I have seen the same problem with the git head for rhythmbox.  I keep my music on a NAS that supports CIFS and NFS so the shared files are 0777.  When I update the ID3 information the owner is changed to my user:my group from the NFS owner:NFS group, and permissions are set to 644.

I am happy to try and work a fix here with a little guidance on where in the code base to start looking.

Well, I'm not saying this is a good patch, but it works for me at least on RB 0.12.3. Until someone smart here comes with a good patch, you can try this or start from here.


*** metadata/rb-metadata-gst.c.orig	2009-08-02 14:13:08.000000000 -0700
--- metadata/rb-metadata-gst.c	2009-08-02 14:12:43.000000000 -0700
***************
*** 1043,1048 ****
--- 1043,1053 ----
  		src = g_file_new_for_uri (tmpname);
  		dest = g_file_new_for_uri (md->priv->uri);
  		
+ 		g_file_copy_attributes ( dest, src, GFILE_COPY_ALL_METADATA, NULL, &io_error);
+ 		if (io_error != NULL) {
+ 			goto gio_error;
+ 		}
+ 
  		g_file_move (src, dest, G_FILE_COPY_OVERWRITE, NULL, NULL, NULL, &io_error);
  		if (io_error != NULL) {
  			goto gio_error;

I forgot, for comment #3 for example you might want to pass G_FILE_COPY_NONE instead and have the directories chmod g+s, that way you can group share and change tags

IMO rhythmbox should respect the file permissions and owner without being told to by the filesystem.  Your posted patch works for me with a small change (G_FILE_COPY_ALL_METADATA instead of GFILE_COPY_METADATA).

Spoke too soon, it works if the user running rhythmbox owns the file in question, but it does not work if the file is owned by someone else.

Yeah I mistyped the flag and didn't want to add a comment for something people were going to find out anyway. 

Of course if you don't own the file then you can't write a file with all the metadata of another user. If what you're looking for is just to keep the chmod permissions for example, then comment 7 should do it for you.

I am seeing what I take to be more evidence for this bug.  I have a server running Ubuntu 9.10 with Rhythmbox 0.12.5.  I maintain a shared directory on that server with permissions set to rw r r.  Whenever I alter or add a tag to a FLAC using Rb the file permissions for the file in question are changed to rw _ _.  I have listed additional information here:

http://ubuntuforums.org/showthread.php?p=8612165

I am happy to answer any questions I am able.

(This was also occurring when I had my music collection on my main machine running 8.10 and 0.11.6 and still occurs on that machine if I choose to ask it to do any local tagging.)

A similar problem persists in Rhythmbox 0.13.1. Setting the tags of an mp3 file changes the permissions from whatever they are to -rw------ (that is, u=rw,go=).

Something like this went in as part of commit 90b7496.  This is all we can do.