Hi Jeff,
Thanks for the further clarification of this problem.
Your description of the problem below -- and on the MS tech forum back in
March -- seems to imply that until this issue is fixed by MS, that there
are potential work-arounds that could be taken by the OpenAFS client.
Possibly undesirable from a developer's perspective, but effective for
end-users... thoughts?
Cheers,
Stephen
On Sat, 19 Oct 2013, Jeffrey Altman wrote:
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
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
