Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copy file from outside the projected filesystem #99

Open
Eznopot opened this issue Jan 22, 2025 · 1 comment
Open

Copy file from outside the projected filesystem #99

Eznopot opened this issue Jan 22, 2025 · 1 comment

Comments

@Eznopot
Copy link

Eznopot commented Jan 22, 2025

I have developed a program using ProjFS to synchronize files between my backend and a Windows session. Everything works as expected within the projected filesystem: I can create, modify, delete, copy, and move files.

However, when I try to copy a file from outside the projected filesystem into it, Explorer.exe gets stuck during the copy process. I don’t receive any errors or logs from ProjFS, which makes it difficult to debug the issue.

Has anyone encountered this problem before or have suggestions on how to resolve it? I can share specific parts of the code if needed.

Thank you in advance for your help!

@Eznopot
Copy link
Author

Eznopot commented Jan 23, 2025

Hello,

I continued investigating the issue, and I found that the problem is caused by Microsoft Defender. During the file copy process, Defender performs a checksum (specifically, opening the file with ifstream), which blocks the file opening operation. As a result, my program was stuck on the following line:
std::ifstream file(filePath, std::ios::binary);

To temporarily address the issue, I started by whitelisting my program's executable in Microsoft Defender. While this approach works, it is not feasible for production in the context of my project.

Instead, I added the following logic in my program during the OPEN event notification to prevent the antivirus from accessing the file:

if (CallbackData->TriggeringProcessImageFileName) {  
    if (EndsWithStringI(CallbackData->TriggeringProcessImageFileName, L"MsMpEng.exe")) {  
        return;  
    }  
}

Although this fix works, it is not ideal or recommended. Does anyone have a better solution for handling this situation?

Thank you in advance for your insights!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant