[OpenAFS] not enough space in target directory
stephen@physics.unc.edu
stephen@physics.unc.edu
Mon, 21 Oct 2013 09:29:04 -0400 (EDT)
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
>
>
>