[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?


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