[GH-ISSUE #37] "The directory name is invalid" for some songs #35

Open
opened 2026-02-27 15:48:01 +03:00 by kerem · 4 comments
Owner

Originally created by @mbharanya on GitHub (Jun 14, 2022).
Original GitHub issue: https://github.com/Rafiuth/Soggfy/issues/37

Setup:

  • Soggfy-2.2.16
  • Windows 10 (in a VM)
  • Spotify for Windows 1.1.87.612.gf8d110e2
  • Saving files to a SMB share on a Linux NAS

Currently for a lot of songs I'm getting the following error messages, mostly when scrolling through my saved songs. It also prevents me from downloading some of the files, as it only creates the folder with the lyrics file, but then is unable to recognize it somehow.

[WRN] Error while processing message from 0x1346f110: directory_iterator::directory_iterator: The directory name is invalid.: "\\?\C:\shortcuts\raid10\Music\Spotify_Downloaded\Architects\Daybreaker"
[WRN] Error while processing message from 0x1346f110: directory_iterator::directory_iterator: The directory name is invalid.: "\\?\C:\shortcuts\raid10\Music\Spotify_Downloaded\While She Sleeps\You Are We"
[WRN] Error while processing message from 0x1346f110: directory_iterator::directory_iterator: The directory name is invalid.: "\\?\C:\shortcuts\raid10\Music\Spotify_Downloaded\Carpenter Brut\Hush Sally, Hush!"

Example C:\shortcuts\raid10\Music\Spotify_Downloaded\Architects\Daybreaker exists, Soggfy was able to create the folder, write the lyrics file, but is unable to save the track after:

$ tree Architects/
Architects/
├── Daybreaker
│   └── 9. Devil's Island.lrc

One guess I have is that it might be be the special characters in songs like Hush Sally, Hush!, Devil's Island. It also happens with songs with spaces in it.

Happy for any pointers!

Originally created by @mbharanya on GitHub (Jun 14, 2022). Original GitHub issue: https://github.com/Rafiuth/Soggfy/issues/37 Setup: - Soggfy-2.2.16 - Windows 10 (in a VM) - Spotify for Windows 1.1.87.612.gf8d110e2 - Saving files to a SMB share on a Linux NAS Currently for a lot of songs I'm getting the following error messages, mostly when scrolling through my saved songs. It also prevents me from downloading some of the files, as it only creates the folder with the lyrics file, but then is unable to recognize it somehow. ``` [WRN] Error while processing message from 0x1346f110: directory_iterator::directory_iterator: The directory name is invalid.: "\\?\C:\shortcuts\raid10\Music\Spotify_Downloaded\Architects\Daybreaker" [WRN] Error while processing message from 0x1346f110: directory_iterator::directory_iterator: The directory name is invalid.: "\\?\C:\shortcuts\raid10\Music\Spotify_Downloaded\While She Sleeps\You Are We" [WRN] Error while processing message from 0x1346f110: directory_iterator::directory_iterator: The directory name is invalid.: "\\?\C:\shortcuts\raid10\Music\Spotify_Downloaded\Carpenter Brut\Hush Sally, Hush!" ``` Example `C:\shortcuts\raid10\Music\Spotify_Downloaded\Architects\Daybreaker` exists, Soggfy was able to create the folder, write the lyrics file, but is unable to save the track after: ``` $ tree Architects/ Architects/ ├── Daybreaker │   └── 9. Devil's Island.lrc ``` One guess I have is that it might be be the special characters in songs like `Hush Sally, Hush!`, `Devil's Island`. It also happens with songs with spaces in it. Happy for any pointers!
Author
Owner

@Rafiuth commented on GitHub (Jun 18, 2022):

The "directory name is invalid" error is a bit weird, I don't think it's because of the \\?\ prefix because from what i've seen it was supported before win10. Did you ever see a check mark before on the playlist tracks?

Also, is C:\shortcuts\raid10 a symlink to the netshare or just a normal directory?

<!-- gh-comment-id:1159455416 --> @Rafiuth commented on GitHub (Jun 18, 2022): The "directory name is invalid" error is a bit weird, I don't think it's because of the `\\?\` prefix because from what i've seen it was supported before win10. Did you ever see a check mark before on the playlist tracks? Also, is `C:\shortcuts\raid10` a symlink to the netshare or just a normal directory?
Author
Owner

@mbharanya commented on GitHub (Jun 18, 2022):

@Rafiuth I created the symlink C:\shortcuts\raid10 pointing to a network share in hopes of fixing the issue. Using \\<ip>\raid10\Music had the same issue.

I do see checkmarks and most songs are able to be downloaded. The error just seems to happen for a few select songs.

<!-- gh-comment-id:1159477460 --> @mbharanya commented on GitHub (Jun 18, 2022): @Rafiuth I created the symlink `C:\shortcuts\raid10` pointing to a network share in hopes of fixing the issue. Using `\\<ip>\raid10\Music` had the same issue. I do see checkmarks and most songs are able to be downloaded. The error just seems to happen for a few select songs.
Author
Owner

@Rafiuth commented on GitHub (Jun 21, 2022):

I've managed to reproduce this issue (or at least a related one) using a Samba server on WSL, but I didn't find a solution. You could workaround it by saving to some temporary path inside the VM and copying it to the NAS later.

Apparently, after calling std::filesystem::exists() on some existing file, the directory containing that file will no longer be recognized as a directory for some period of time. When Soggfy tries to save a track, the create_directories() call will throw an exception because it thinks that the path is a file and not a directory. The exception should be caught and logged as [ERR] Failed to save track, but it just crashes Spotify for me. I believe it also causes the "invalid directory name" error.

I've isolated a minimal repro which works most of the time, but the bug could be anywhere on the MSVC STL, Windows or Samba (most likely?):

//`Z:\` is a mounted netshare to a samba server running on WSL.
#include <fstream>
#include <iostream>
#include <filesystem>
#include <Windows.h>
namespace fs = std::filesystem;

int main(int argc, char* argv[]) {
    if (argc == 2) {
        fs::create_directories("Z:/Folder1/Folder 2");
        std::ofstream("Z:/Folder1/Folder 2/File 1.txt", std::ios::binary | std::ios::trunc) << "Hello World";
    }
    std::cout << "AttrsBefore: " << GetFileAttributesW(L"Z:/Folder1/Folder 2") << "\n";
    std::cout << "Exists: " << fs::exists("Z:/Folder1/Folder 2/File 1.txt") << "\n";
    std::cout << "AttrsAfter: " << GetFileAttributesW(L"Z:/Folder1/Folder 2") << "\n";
    return 0;
}

Output:

E:\repro>cl /std:c++17 Main.cpp

E:\repro>Main.exe a
AttrsBefore: 32
Exists: 1
AttrsAfter: 32

E:\repro>Main.exe
AttrsBefore: 16
Exists: 1
AttrsAfter: 16

E:\repro>Main.exe
AttrsBefore: 16
Exists: 1
AttrsAfter: 32

(about 30s wait between each run)

As per spec, 32=FILE_ATTRIBUTE_ARCHIVE and 16=FILE_ATTRIBUTE_DIRECTORY.

<!-- gh-comment-id:1161123865 --> @Rafiuth commented on GitHub (Jun 21, 2022): I've managed to reproduce this issue (or at least a related one) using a Samba server on WSL, but I didn't find a solution. You could workaround it by saving to some temporary path inside the VM and copying it to the NAS later. Apparently, after calling `std::filesystem::exists()` on some existing file, the directory containing that file will no longer be recognized as a directory for some period of time. When Soggfy tries to save a track, the create_directories() call will throw an exception because it thinks that the path is a file and not a directory. The exception should be caught and logged as `[ERR] Failed to save track`, but it just crashes Spotify for me. I believe it also causes the "invalid directory name" error. I've isolated a minimal repro which works most of the time, but the bug could be anywhere on the MSVC STL, Windows or Samba (most likely?): <details> ```cpp //`Z:\` is a mounted netshare to a samba server running on WSL. #include <fstream> #include <iostream> #include <filesystem> #include <Windows.h> namespace fs = std::filesystem; int main(int argc, char* argv[]) { if (argc == 2) { fs::create_directories("Z:/Folder1/Folder 2"); std::ofstream("Z:/Folder1/Folder 2/File 1.txt", std::ios::binary | std::ios::trunc) << "Hello World"; } std::cout << "AttrsBefore: " << GetFileAttributesW(L"Z:/Folder1/Folder 2") << "\n"; std::cout << "Exists: " << fs::exists("Z:/Folder1/Folder 2/File 1.txt") << "\n"; std::cout << "AttrsAfter: " << GetFileAttributesW(L"Z:/Folder1/Folder 2") << "\n"; return 0; } ``` Output: ``` E:\repro>cl /std:c++17 Main.cpp E:\repro>Main.exe a AttrsBefore: 32 Exists: 1 AttrsAfter: 32 E:\repro>Main.exe AttrsBefore: 16 Exists: 1 AttrsAfter: 16 E:\repro>Main.exe AttrsBefore: 16 Exists: 1 AttrsAfter: 32 (about 30s wait between each run) ``` [As per spec](https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants), 32=FILE_ATTRIBUTE_ARCHIVE and 16=FILE_ATTRIBUTE_DIRECTORY. </details>
Author
Owner

@mbharanya commented on GitHub (Jun 21, 2022):

@Rafiuth Thank you so much for the thorough investigation. This really seems interesting, if something like std::filesystem::exists() fails for such a use case.

I've just been trying to isolate if the issue only persists for network shares, and so far it seems that mounting the directory as a shared folder in VMware seems to no longer throw that error. I'll be watching it though, as it happened quite infrequently. This way it's still a "network" drive, but probably uses a different protocol than SMB.

<!-- gh-comment-id:1162001343 --> @mbharanya commented on GitHub (Jun 21, 2022): @Rafiuth Thank you so much for the thorough investigation. This really seems interesting, if something like ` std::filesystem::exists()` fails for such a use case. I've just been trying to isolate if the issue only persists for network shares, and so far it seems that mounting the directory as a shared folder in VMware seems to no longer throw that error. I'll be watching it though, as it happened quite infrequently. This way it's still a "network" drive, but probably uses a different protocol than SMB.
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Soggfy#35
No description provided.