FoksSerg еще раз посмотрел код в этом месте. Запись тегов, как и любая другая модификация исходного файла делается максимально безопасным образом (чтобы не потерять файл из-за сбоев в файловой системе, а такое хоть редко, но случается) - сначала пишется еще один файл на диск, и только если он записался без ошибок, новый переименовывается в старый, с удалением старого. Это я к тому, что там много всего происходит, и если какая-то из операций не удастся, будет ошибка. А если будет ошибка - то в базе данных не обновится тег.
С учетом выше описанного, понятия не имею, как вообще могла произойти описанная ситуация. Программа, видимо, искренне была уверена, что операция записи прошла успешно, иначе старый тег бы не пропал из списка для тех файлов, для которых запись не удалась.
Кроме того, программа даже обновила в базе данных хеш и дату модификации файла, а дату модификации она СЧИТЫВАЕТ С ДИСКА перед записью в базу. То есть по сути уже делает именно то, о чем вы писали - проверяет, прошла ли запись.
Однако, позже программа обнаружила, что дата модификации и контрольная сумма у файла на диске отличается от той, что в базе, и заново переиндексировала файл (иначе старые теги не могли появиться).
Это я к тому, что пока выглядит так, что программа на своей стороне делает все необходимые проверки, а кто-то другой её дурит. Делает вид, что файл записался, но потом откатывает все изменения. Может у вас с сетевым соединением есть какие-то глюки?
