Virtualization scheme Version 2 causing extremely slow file deleting speed using del /f /s /q /A:- ::::C

[0x391F]

Describe what you noticed and did

Virtualization scheme Version 2 causing extremely slow speed when using del /f /s /q /A:- ::::C to delete files (!!!Warning!!! DO NOT run it in REAL system!!! Replace ::::C with C:)

How often did you encounter it so far?

No response

Expected behavior

It should as fast as Virtualization scheme Version 1.

Affected program

cmd.exe

Download link

N/A

Where is the program located?

The program is installed only outside the sandbox.

Did the program or any related process close unexpectedly?

No, not at all.

Crash dump

No response

What version of Sandboxie are you running now?

Sandboxie v1.13.0

Is it a new installation of Sandboxie?

I just updated Sandboxie from a previous version (I don't remember which one).

Is it a regression from previous versions?

No response

In which sandbox type you have this problem?

Not relevant to my request.

Can you reproduce this problem on a new empty sandbox?

I can confirm it also on a new empty sandbox.

What is your Windows edition and version?

Windows 10 Enterprise LTSC 2021 x64 (21H2)

In which Windows account you have this problem?

An account with UAC protection set to Always notify.

Please mention any installed security software

ESET Internet Security 17.0.16.0

Did you previously enable some security policy settings outside Sandboxie?

No response

Trace log

No response

Sandboxie.ini configuration

No response

[bastik-1001]

Just for my curiosity, did you notice other performance degradation from scheme 1 to scheme 2?

[offhub]

The problem is that the time increases exponentially as the number of files/folders processed increases.

UseFileDeleteV2=n

UseFileDeleteV2=y

[DavidXanatos]

Yea, I'm not sure how to easily fix this, the issue is that each time something gets deleted we need to update the FilePaths.dat file.

The proper fix would be to let the service maintain a cached database but then we would need to query the service on every file operation, or alternatively keep a per process cache but use the service to maintain the FilePaths.dat file and push updates to all running processes. That would be overall slower but would have constant performance no mater how many files get deleted.

In my opinion deleting a lot of host files within the sandbox is a rare use case hence the current tradeoff overall is beneficial.

That said assuming no contention for the FilePaths.dat we could improve the update procedure to not re create the entire file from scratch, but only append entries if the file was not modified in the mean time.

[bastik-1001]

Thank you for the explanation.

That said assuming no contention for the FilePaths.dat we could improve the update procedure to not re create the entire file from scratch, but only append entries if the file was not modified in the mean time.

While I don't know how much of a reduction this will bring, it sounds like an improvement.

[DavidXanatos]

It would help a lot, and now that I think of it, we should improve also on the edge case of thousands of files on one directory, this is also not handled ideally

[bastik-1001]

@offhub, Can you give some examples again, to show by how much it was improved?

[DavidXanatos]

Not its as fast as scheme V1 the differenc is withing the error margin.

[offhub]

Old (~319 secs)

New (~24 secs)