On 10/15/2013 7:07 PM, Ian Crowther wrote: > One thing I noticed in my case was that process monitor reported that > explorer checked free space on the root volume instead of the volume > that was being written to.
That is the underlying problem. Instead of using GetVolumeInformationByHandleW() called on the destination directory the Explorer Shell is using GetVolumeInformation() which must be provided the root directory of the volume. When the Explorer Shell gets the root directory wrong and choose say the root of a drive letter mapping, then it gets the wrong volume attributes and free space. > Would somehow ensuring that the AFS server's root volume reports > sufficient free space be an adequate workaround? I have no idea, but > if I were still affected I'd try it... Readonly volumes have 0 bytes free. That is why this is a problem for AFS and not Windows File Shares. Windows doesn't support the concept of booting from a readonly volume and then accessing writable areas from a read/write volume. If it did, the Explorer Shell would be immune to this issue. The problem doesn't occur all of the time and Microsoft doesn't have internal AFS to test against so it is a challenge for them. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
