As far as I remember, in that case you still will be able to get a directory handle (with appropriate permissions), but calling FlushFileBuffers() on it is going to fail.
So you can test for that in advance before the restore and switch to syncing each file individually. Or accept that the approach only works locally and do nothing more, since durability over SMB is a questionable thing.
As far I remember NAND/NOR memory (used for SSD) is very slow to *erase*. The erase operation can be performed only by big chunks, requires higher voltage etc.
SSD vendors circumvent this by adding several layers of write buffers to achieve good test results.
So, what is the solution for the SMB part?
As far as I remember, in that case you still will be able to get a directory handle (with appropriate permissions), but calling FlushFileBuffers() on it is going to fail.
So you can test for that in advance before the restore and switch to syncing each file individually. Or accept that the approach only works locally and do nothing more, since durability over SMB is a questionable thing.
Sounds like writing to disk always takes an unacceptably long time, so we should stop writing to disk and do something else.
/s
It's actually quite amusing how modern OSes can abstract, speed up and hide away those things that are still slow even on nowadays hardware.
As far I remember NAND/NOR memory (used for SSD) is very slow to *erase*. The erase operation can be performed only by big chunks, requires higher voltage etc.
SSD vendors circumvent this by adding several layers of write buffers to achieve good test results.