# Leaves .tmp files lying around
**URL:** https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190
**Category:** Support
**Created:** [May 13, 2021, 3:57am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190 "2021-05-13T03:57:55Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@xpusostomos](https://community.mp3tag.de/u/xpusostomos)
#### Post date: [May 13, 2021, 3:57am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/1 "2021-05-13T03:57:55Z")
Problem 1: When mp3tag can't write to the file (or at least, that the message it is giving me.), it leaves a .tmp file lying around.
Problem 2: I'm getting the error "cannot be opened for writing" on certain files I have, even though they clearly are writable. I know that because i checked the permissions are exactly the same as other files that it works with, and I also tried writing to the file myself, as well as copying it to another filename. So I assume "cannot be opened for writing" is actually some other problem with the file. Needs a better error message.
Problem 3: I don't know why this particular movie file can't be edited. I've got 100 files from the same source, 2 of them don't work with mp3tag. Maybe there is something wrong with the files. I can't tell what. A bit tricky to supply the file for diagnostics since it's over a gigabyte.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 13, 2021, 7:41am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/2 "2021-05-13T07:41:54Z")
see e.g. [here](https://community.mp3tag.de/t/f-leftover-tmp-file-if-media-file-could-not-be-opened-for-writing/12001/4)
Also, please use the search function of the forum to see reasons why files cannot be accessed - there are numerous threads about that topic. And in most cases it is a problem of the local environment.
---
### Author:  [@xpusostomos](https://community.mp3tag.de/u/xpusostomos)
#### Post date: [May 15, 2021, 1:41am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/3 "2021-05-15T01:41:40Z")
I can't believe someone considers leaving junk files lying around is a feature. If there's really a reason for it, which I would question, then ask the user before doing it. Certainly if things failed then you already bugged the user with dialog boxes anyway, so give them the choice.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [May 15, 2021, 6:02am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/4 "2021-05-15T06:02:42Z")
I'd consider it a feature in certain circumstances — e.g., if an error occurs between deleting the original file and moving the temporary file to the original location. This way, you wouldn't loose data and can recover from the temp file.
But from your description, it seems to not be so serious and just annoying for you. Not sure if the original file already contains the changes or not, but in either case, dealing with the temporary files is usually not an interesting task. I'm trying to do my best in making that as transparent for the user and at the same time not risking loosing data.
It's possible that both 1.) and 2.) are the result of another application blocking exclusive access to the files. Possible candidates are all kinds of sync services as Google Drive, OneDrive, ... and virus scanners — the latter are usually not so problematic. Can this be the case? Are those MP4 files?
Regarding 3.) I can't really tell from afar. Either you upload the file somewhere and I'll have a look or we leave it as it is.
---
### Author:  [@xpusostomos](https://community.mp3tag.de/u/xpusostomos)
#### Post date: [May 15, 2021, 9:42am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/5 "2021-05-15T09:42:24Z")
Huh what? Are you implying that the user can can lose data if they don't understand the intricacies of this .tmp file? That's ridiculous. Firstly the program should make every effort to guard against that by moving the original first, (mv ABCD.mp4 ABCD-original.mp4) then opening the new file (open ABCD.mp4) before doing any work, and if anything goes wrong during this process, backing out (mv ABCD-original ABCD.mp4) and putting the file back. And if in a rare pathological case that isn't possible, the tmp file should look very close to the original so that the user has a clue that this file is important. e.g. if the original file was "ABCD.mp4" then it should be moved to "ABCD-original.mp4". Then the worst case is the file is left with a slightly odd name from which the user might deduce what happened.
---
### Author:  [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [May 15, 2021, 11:25am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/6 "2021-05-15T11:25:22Z")
So when you are working on a large library of say 25k files and are applying a change to all, mp3tag should create 25k copies? Seems far more likely for errors and disk space problems than dealing with one temp file that appears only IF something goes wrong.
---
### Author:  [@xpusostomos](https://community.mp3tag.de/u/xpusostomos)
#### Post date: [May 15, 2021, 11:49am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/7 "2021-05-15T11:49:20Z")
Which story are you guys running with, that you need to "move a temporary file to the original location" with a brand new file, or not? If you're modifying the original in place, then are what are we even talking about? Either you need a second copy, or you don't. If you don't, then all talk about "deleting the original file" is nonsense.
---
### Author:  [@xpusostomos](https://community.mp3tag.de/u/xpusostomos)
#### Post date: [May 15, 2021, 11:58am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/8 "2021-05-15T11:58:16Z")
I might also add, why do I need to do some search of the forums to see why the heck it failed? Either it failed because of some OS issue (permissions etc), or because the file is corrupt somehow. But when I search on this issue in the forums I find various people talking about corrupt files giving this error. Surely we can give a better error than "write failed" when the file is corrupt. I cannot believe in my case that it is an OS issue because I looked very carefully at permissions, and I tried writing the file myself. So it cannot be. If the file is corrupt, it should say so plainly.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 15, 2021, 11:59am UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/9 "2021-05-15T11:59:05Z")
> [@xpusostomos](#):
>
> Either you need a second copy, or you don't.
Exactly.
You don't need a copy of the file if the modifications fit into the existing padding.
If the padding is too small, a work copy is created and later copied back to the original location.
---
### Author:  [@xpusostomos](https://community.mp3tag.de/u/xpusostomos)
#### Post date: [May 15, 2021, 12:00pm UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/10 "2021-05-15T12:00:22Z")
@ohrenkino ok... and how do I lose data in either scenario requiring me to keep this tmp file?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 15, 2021, 12:00pm UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/11 "2021-05-15T12:00:24Z")
> [@xpusostomos](#):
>
> Surely we can give a better error than "write failed" when the file is corrupt. I cannot believe in my case that it is an OS issue because I looked very carefully at permissions
What about other programs that access the file at the same time? You already got a list of frequent culprits. Maybe you have something even more exotic.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 15, 2021, 12:02pm UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/12 "2021-05-15T12:02:04Z")
> [@xpusostomos](#):
>
> how do I lose data in either scenario requiring me to keep this tmp file
That depends where you look: the original file will then not show the modification.
If you don't want to repeat the whole process, then the tmp file may be a shortcut.
---
### Author:  [@xpusostomos](https://community.mp3tag.de/u/xpusostomos)
#### Post date: [May 15, 2021, 12:02pm UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/13 "2021-05-15T12:02:24Z")
If another program is accessing the file, how come I can write to it? Home come a 2nd copy of the same file gives the same error? Very clearly this must be a corrupt file, and yet mp3tag gives the stupid error that "write failed".
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 15, 2021, 12:03pm UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/14 "2021-05-15T12:03:11Z")
> [@xpusostomos](#):
>
> stupid error
I most certainly don't like the tone of this. Calm down.
---
### Author:  [@xpusostomos](https://community.mp3tag.de/u/xpusostomos)
#### Post date: [May 15, 2021, 12:04pm UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/15 "2021-05-15T12:04:07Z")
As I said before, if the tmp file has some use, fine let the user choose to keep it. Don't just dump it there, assuming the user knows what it is.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 15, 2021, 12:05pm UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/16 "2021-05-15T12:05:39Z")
Is this a change request?
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:29pm UTC](https://community.mp3tag.de/t/leaves-tmp-files-lying-around/53190/17 "2026-02-09T12:29:14Z")