# Keep track of moved files also when aborting the operation

**URL:** https://community.mp3tag.de/t/keep-track-of-moved-files-also-when-aborting-the-operation/47099
**Category:** General Discussion
**Created:** [November 20, 2019, 2:31pm UTC](https://community.mp3tag.de/t/keep-track-of-moved-files-also-when-aborting-the-operation/47099 "2019-11-20T14:31:45Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Zerow](https://community.mp3tag.de/user_avatar/community.mp3tag.de/zerow/32/11379_2.png) [@Zerow](https://community.mp3tag.de/u/Zerow)
#### Post date: [November 20, 2019, 2:31pm UTC](https://community.mp3tag.de/t/keep-track-of-moved-files-also-when-aborting-the-operation/47099/1 "2019-11-20T14:31:45Z")

</div>

How to replicate his bug:

1] Load at least 2 files, one of them other than MP3

2] Play that non-MP3 file in your player

3] Select both of files

4] Choose for them `Move...` from the right click menu

5] When prompted by operating system about that one file being in use [by the player] choose `Skip` or `Cancel`

6] When prompted by Mp3tag about re-reading of the directory choose `No`  
` `  
` `  
What happens? Mp3tag looses from sight both of the files, leaving on the list of files empty "files"; ghosts, shells, whatever you wanna call it. The have tag fields wiped out of data and fle themselves cannot be accessed by Mp3tag anymore

Prevention: do not move files like FLAC that are being played. But the user might simply make a mistake

Workaround: reread the directory. But the user might had loaded up multiple directories or some kind of a large collection, making the re-read option useless [i.e. not precise enough on the account of not rereading others folders] or too time consuming [in case of a tens of thousands of files on the list infected now with "ghost" files]

Solution: simply keep track of the moved files