https://bugs.kde.org/show_bug.cgi?id=434551
--- Comment #4 from Till Schäfer <till2.schae...@uni-dortmund.de> --- I have tried to reproduce the bug for later taglib testing and I can not reliably reprocude it (see below). I like do share the insight about OggFlacMetadata behavior before I continue testing with taglib. 1. play a track A in kid3 2. remove a picture block of A 3. save (takes some time over a slow connection) -> a dialog appears: "Error while writing file" (see attachment "dialog error writing"). At this point the track is still present. 4. select another track B for playing in kid3 5. save track A (applies imideately)-> now another dialog (YES/NO question) appears: "Error while writing file. Do you want to change the permissions?" (see attachment "dialog change permissions"). At point 5 Track 4 is already lost. Thus, the answer does not change any outcome. Hence, it seems there might be some behavior of kid3, that is actually involved in triggering the bug" - May it be, that the play feature does not properly close a file handler of A when playing B? - Somehow kid3/libflac seems to reuse the previously saved metadata_edit file on the second save. Independent of kid3 i sometimes observe on my network drive, that some file operations, e.g., deletion of files, do not immediately appear in my filemanager. In this situation I sometimes need to refresh the content of the folder to actually see the change. Thus, my guess here is that the problem somehow occurs with locking and not released files. Thus, kid3/libflac somehow assumes, that the metadata_file is still present, but actually it is not. Or, the file handle is still there, but the file is in some "to delete when file handle is release" state, such as described in another context here: https://github.com/atom/atom/issues/10596 => maybe kid3 can do something here by properly closing handled and/or syncing the folder content before the second save. -- You are receiving this mail because: You are watching all bug changes.
