When using id3v2 utility, I found that when stripping id3v1 tags, file GID
changes to current GID. When stripping only id3v2 tags, the behaviour is
normal. I look at the documentation and source code of id3v2 package and
found calls to libid3 library. Example how to reproduce it:

user@hostname:~$ ls -l 01.mp3
-rw-rw---- 1 user audio 8034304 Jun 18 08:43 01.mp3
#                 ^^^^^
user@hostname:~$ id3v2 -d 01.mp3
Stripping id3 tag in "01.mp3"...id3v2 stripped.
user@hostname:~$ ls -l 01.mp3
-rw-rw---- 1 user audio 8032660 Jun 18 08:44 01.mp3
#                 ^^^^^ - All OK
# add some tags...
user@hostname:~$ id3v2 -y 2000 01.mp3
user@hostname:~$ id3v2 -s 01.mp3
Stripping id3 tag in "01.mp3"...id3v1 stripped.
user@hostname:~$ ls -l 01.mp3
-rw-rw---- 1 user user 8034176 Jun 18 08:44 01.mp3
#                 ^^^^ - ???

First of all, sorry for the delay.

This sounds like it might be somewhat annoying. Unfortunately I am
currently unable to reproduce the problem. Could you maybe check
whether the same thing happens on a different machine too?

cheers

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

We believe that the bug you reported is fixed in the latest version of
id3lib3.8.3, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 630957@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Martin A. Godisch <godisch@debian.org> (supplier of updated id3lib3.8.3 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 19 Jun 2026 11:46:38 +0200
Source: id3lib3.8.3
Architecture: source
Version: 3.8.3-22
Distribution: unstable
Urgency: low
Maintainer: Martin A. Godisch <godisch@debian.org>
Changed-By: Martin A. Godisch <godisch@debian.org>
Closes: 630957 1098206
Changes:
 id3lib3.8.3 (3.8.3-22) unstable; urgency=low
 .
   * Add 69-fix-bool-typedef-c23.patch: in the C (non-C++) path of globals.h,
     include <stdbool.h> from C99 onwards instead of "typedef int bool". The
     legacy typedef is a hard error in C23 (the GCC 15 default), so id3.h
     (which pulls in globals.h) could no longer be included from C23 code.
     The typedef is kept only as a fallback for pre-C99 compilers. As a side
     effect this aligns the C view of bool with the C++ ABI the library is
     actually built with, without a SONAME change. Closes: #1098206.
   * Add 70-warn-on-unsupported-id3v2-version.patch: print a one-line notice to
     stderr when a v2 tag header reports a version newer than ID3v2.3.0 or an
     unrecognised version (e.g. ID3v2.4), instead of discarding the tag
     silently. This adds no ID3v2.4 parsing and does not change parsing
     behaviour. Re: #449186 (not closed; full ID3v2.4 support is out of scope).
   * Add 71-preserve-file-owner-on-rewrite.patch: when RenderV2ToFile() rewrites
     a file via a temporary file and rename(2) (needed when an ID3v2 tag is
     prepended or grown), restore the original owner and group with a
     best-effort chown(2) in addition to the existing chmod(2). This stops the
     file's group from changing silently. Closes: #630957.
Checksums-Sha1:
 4f6338a6cc5a4515d0e26d8ecc3cb9fdb81a0b99 2169 id3lib3.8.3_3.8.3-22.dsc
 cd8f3e747e84244d93ae8df3079e68e7bfb7c8a1 19396 id3lib3.8.3_3.8.3-22.debian.tar.xz
 c010ac31efd509a5541fcc88dbe94d16a3ab1696 7987 id3lib3.8.3_3.8.3-22_amd64.buildinfo
Checksums-Sha256:
 bc10249b1d6240bd4f7b797898a7c3a22104a951d8a3c6136b8ca49358f1511a 2169 id3lib3.8.3_3.8.3-22.dsc
 b914ab5e725a1f2f20f6ee1c86080c01729b2cec84587c8aa437366372d08d34 19396 id3lib3.8.3_3.8.3-22.debian.tar.xz
 f51eae57c6785ee09f1e8542701c2c7b33c32b439078c062d5382b9ae9c24179 7987 id3lib3.8.3_3.8.3-22_amd64.buildinfo
Files:
 cde8c43c6e6aaeac8e19714d80550a79 2169 libs optional id3lib3.8.3_3.8.3-22.dsc
 11c669d3608fa16b0676f1b0768930be 19396 libs optional id3lib3.8.3_3.8.3-22.debian.tar.xz
 18f42b57238e133e35ddc26b09db8641 7987 libs optional id3lib3.8.3_3.8.3-22_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJHBAEBCgAxFiEEGEIyO0/Pm5CZX6F/o1C5kfBaSFcFAmo1EM8THGdvZGlzY2hA
ZGViaWFuLm9yZwAKCRCjULmR8FpIV4//D/9OkChwmpY5aJ4dROFJGrh5NLRhAxqO
4mVsMSJVq96wa7Ertz88T0qPr8f9iXBQlg23cRjkB4UHsYQqAqfcWB0g+8/SgHtg
IUGB1BcyvIjPTeczOo4OZANu8OR/CRKKgvVoi8HvXs3kUmiUdViUM9iM92XW9ogT
K70dy9YuserNcLM+EwQuCBjtqN/9n2q28xfvMD7iQ3m5mD7HdwagSDmUtpUjYkd0
k+PF2lbtvOxbqcGJ3y17i6uwhjVtX6ftFdnilSm3QhZ0YAlWO13R04AeiwPm/R2J
cHksLlaKJPNZ9YKQ/9sD8u6FkomcxFFKISnFBdF8XIue1GnR6r6HzZj2biKCVJNc
dKU2MqSGnPmcCYjrK28/ua650NM81oqBnE+hYvY7qxTICV/8t4/p2XKZbeZaLeo1
k6WMEV/lLEdLdqY2bwRSDVqdYzbvyZcRs+ziCQT497pwL8hZtHu8qcFkYmNQIV9g
cSCNH7VeFaiYRw4rQhzOdC9ELghwJzlH+srfNg40tGX2o3UzJlUKf7J71eecDUw2
hOCOcFj3GxVyZ/phEKJ+fCLoDMJ4bHh3WZMZHu3BuSLDHVja95IKlbpetlu9F9Ya
RM4dI7tcpZEpHfb3za2uXfzu/Hvw7gRVSUq9lbFV/WCvthqfYu18ZZ0KzRrGRhlu
RYa5qxuP5lz+og==
=J7t1
-----END PGP SIGNATURE-----