GNOME Bugzilla – Bug 729664
Files are deleted on smb share if Tag data changed
Last modified: 2018-05-24 18:14:51 UTC
Overview: With the following system environment i get lost of my mp3 files on a samba mounted share. My system (Ubuntu 14.04) is connected to a Synology NAS (network attached storage) system which contains my music library. So i configured rhythmbox to use a samba share to the NAS as my music library location (smb://diskstation/music/). Everything works fine. The rhythmbox music library is filled with all music files from this samba share and playback works also without any problems. But if i try to change the Tag data of a song which is currently playing, after a few seconds there is an error message "Fehler beim Speichern der Titelinformationen - Die Datei existiert bereits" (Translated this may be something like "Error saving title information - file already exists"). After that message, the currently playing mp3 file on the samba share is gone. Rhythmbox plays the current song until the end, but the next time i want to play the song (double click on it) it is removed from the rhythmbox music library and listed in the "missing files" section of my music library. I can see directly on my NAS, that the file is deleted and i can only restore it from the recycle bin of my NAS storage. Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps. 1) Setup Rhythmbox to use a synology NAS samba share (Bearbeiten -> Einstellungen -> Musik -> "Musikdateien sind abgelegt in:" <smb://diskstation/music/>) and activate the flag "Die Musiksammlung auf neue Dateien hin überwachen". 2) Play a song from the music library which is located on the samba share. 3) Edit the tag information of this song (e.g. add "test" to the "title") 4) After a few seconds (approx. 5 seconds) a message will appear saying that the file already exists. 5) Double click the currently playing file again and it is removed from the music library. Actual Results: The current music file is deleted on the NAS! Expected Results: The file should still be there and available in the music library, but with the old tag information. Build Date & Platform: Rhythmbox 3.0.2 on Ubuntu 14.04 with updates from 6.5.2014 Additional Information: This problem is only reproducable with music located on my NAS. If the music files are on my local hard drive i can change tag data and play the music in parallel without any problems.
Rhythmbox performs tag editing by writing a new copy of the file with the updated tags, then moving it over the original copy. smb apparently can't do this as a single operation, so the gvfs smb backend unlinks the destination file if it already exists, then does the rename. Based on your description of the end result, your NAS is unlinking the destination file, then failing the rename claiming that the destination file still exists. Can you reproduce this behaviour with other smb servers?
Hi. I have tried it locally on my ubuntu installation. I shared a local directory to the network and access it with smb in rhythmbox. After that i played a song from this samba source and edit the tag information. Now i get the same error message (file already exists), but the file is not!! deleted and still available. Thats OK. I dont have any other samba servers available at the moment to do further testing. The samba version of my NAS is a customized version: Version 3.6.9 Synology Build 4482, Apr 17 2014 16:43:17 At the moment i cannot use rhytmbox together with my smb share on the NAS because i am afraid of losing more files. Are there any terminal calls i can run in a small script to reproduce this? With this information a bug report for synology could be opened, if it is a special problem of this one manufacturer. Is it also possible to secure the "unlink" and "rename" process? Perhaps with a check if the file which should be modified is accessed at the moment. Thanks for your help.
(In reply to comment #1) > Rhythmbox performs tag editing by writing a new copy of the file with the > updated tags, then moving it over the original copy. > > smb apparently can't do this as a single operation, so the gvfs smb backend > unlinks the destination file if it already exists, then does the rename. > Shouldn't the gvfs backend do a rename of the original file to a temporary file instead of deleting it, and do a rollback if the rename of the new file fails? This seems like a bug in the gvfs smb backend.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/1341.