# MP3Tag shortens cover-file names in some cases
**URL:** https://community.mp3tag.de/t/mp3tag-shortens-cover-file-names-in-some-cases/62096
**Category:** Support
**Created:** [September 10, 2023, 7:58am UTC](https://community.mp3tag.de/t/mp3tag-shortens-cover-file-names-in-some-cases/62096 "2023-09-10T07:58:35Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [September 10, 2023, 7:58am UTC](https://community.mp3tag.de/t/mp3tag-shortens-cover-file-names-in-some-cases/62096/1 "2023-09-10T07:58:35Z")
MP3Tag saves cover files that are obtained from a web source or extracted from a music file with a file name defined in File-\>Options-\>Tag Sources.
The definition I use is `%albumartist% - %album% - Front`. Together with a folder structure according to `%albumartist%\ %album%` it can lead to overly long filenames including paths, especially with classical music, which Windows has been able to handle for some time now. Basically, I still try to avoid paths that are too long.
I noticed the following inconsistent behavior of Mp3Tag with different storage methods.
1. Saving a cover file via a web source with “Save cover to disc” activated works without any problems.
2. Exporting an embedded cover using an “Export Cover to file” action works without any problems.
3. However, extracting (via right mouse click) from the displayed cover of the web source or the tag panel or the expanded tag view creates a cover file name that is apparently automatically shortened to correspond to the traditional filename-length in Windows.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [September 14, 2023, 12:26pm UTC](https://community.mp3tag.de/t/mp3tag-shortens-cover-file-names-in-some-cases/62096/2 "2023-09-14T12:26:29Z")
Thank you for the detailed report. Unfortunately, it's a limitation of the Windows file dialog, which automatically truncates the filename even if I provide it with the long path prefix.
In cases 1. and 2., I'm using lower-level Win32 functions which support long file paths.
---
### Author:  [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [December 21, 2023, 11:23am UTC](https://community.mp3tag.de/t/mp3tag-shortens-cover-file-names-in-some-cases/62096/3 "2023-12-21T11:23:17Z")
I'm taking up the topic again because a new aspect has emerged in practical work. Normally, I now make sure that the "Extract Cover" function does not fall into the trap described above of shortening the file names. But now it happened to me on an album that I executed the function despite the path being too long. That led to a problem that I can reproduce with this album and the special environment:
Right click on Cover -\> Extract Cover
The shortened file name for saving is displayed. When saving, however, the displayed file name is shortened again by 8 characters including the file extension and the dot.. For this special file, a file name is created without a file extension and with a space at the end.
The consequence:
This file cannot be deleted, copied, moved or renamed. Even deleting it with del in the DOS window didn't work. Likewise, higher-level folders cannot be copied. The error message always says that this file does not exist. In Explorer the file is displayed with its expected size, in the properties of the file with 0 bytes. CHKDSK reported no problem.
I ultimately solved the problem with this command in the DOS window after I isolated the file (moving away other files in the folder):
`del "\\?\E:\Dateipfad\*.*"`
I followed "Cause 6" in this article:
> **[Can't delete files on NTFS file system - Windows Server](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/cannot-delete-file-folder-on-ntfs-file-system#resolution-2-rename-or-move-a-deep-folder)**
>
> Describes why you can't delete a file or folder on an NTS file system volume. Provides resolutions for each of the possible causes.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:30pm UTC](https://community.mp3tag.de/t/mp3tag-shortens-cover-file-names-in-some-cases/62096/4 "2026-02-09T12:30:09Z")