"The directory name is invalid" for some songs

[mbharanya]

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!

[Rafiuth]

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?

[mbharanya]

@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.

[Rafiuth]

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.

[mbharanya]

@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.