# Exporting coverart as filename is not saving exactly as it should **URL:** https://community.mp3tag.de/t/exporting-coverart-as-filename-is-not-saving-exactly-as-it-should/41670 **Category:** Support **Created:** [May 11, 2018, 11:35am UTC](https://community.mp3tag.de/t/exporting-coverart-as-filename-is-not-saving-exactly-as-it-should/41670 "2018-05-11T11:35:41Z") **Posts on this page:** 1 **Showing post:** 4
### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino) #### Post date: [May 11, 2018, 4:22pm UTC](https://community.mp3tag.de/t/exporting-coverart-as-filename-is-not-saving-exactly-as-it-should/41670/4 "2018-05-11T16:22:45Z")
> [@irishwill2008](#): > > On a side note, why the hell did the devs design it so it removes ending spaces? there is a thread from 2010: > [@MP3tag can't handle spaces in filename between file name and .mp3](https://community.mp3tag.de/t/mp3tag-cant-handle-spaces-in-filename-between-file-name-and-mp3/10865/3): > > There is an entry in the Change Log ... [2010-03-13] REL: VERSION 2.46 (for Windows XP/2003/Vista/2008/7) [2010-03-10] FIX: blanks before extension part in file names were automatically removed at Replace actions for \_FILENAME. Points your discussion post to this fact? If so, then there might be something to report relating to Mp3tag 2.46c. The Return of the Bug -.-.--.=.`oo´ Having a filebasename of "test .mp3" and using action "Replace" to replace the string part "test" with nothin… > [@irishwill2008](#): > > Stupidily designed. Talking about design questions: > [@irishwill2008](#): > > sadly removing the space is not an option here as it will mess up our references etc in our DB I wonder if the DB is really designed in such a way that one cannot adapt the references so that the files without trailing space will be found again ... --- _[View the full topic](https://community.mp3tag.de/t/exporting-coverart-as-filename-is-not-saving-exactly-as-it-should/41670)._