Well then The way I understand it this happens because if a file lacks id3v2 tags, libid3 creates a new file and puts the tags + the contents of the previous file in there. The newly created file will then belong to the current user's primary group.
We could try to chown the new file after writing but that would probably fail in many cases. We could also try to write the new data into the existing file which would however lead to data corruption if the file cannot be written (eg. if the disk is full). The only reasonably fail-safe way to update the file that I can currently think of would be to create a backup of the original file, try to update the file with the new data and then delete / restore the backup, depending on whether or not the writing operation was successful. Considering the rather poor general state of libid3 I will not be spending time implementing this right now and I'll tag this bug as "wontfix"; I will gladly accept third-party patches to fix this issue though. cheers -- Stefan Ott http://www.ott.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
