This problem is affecting us as well.
I'm not entirely convinced this problem couldn't be fixed with some AFS client
trickery.
Our issue is that we have a drive mapped to the cell root.
Since our drive is mapped to the root, the application 'thinks' the entire file
system on that 'drive' is one 'volume'.
Some of our applications try to be 'smart' and check the 'disk free' before
they perform their writes.
(Note: In my history as a programmer, we would just open the file for 'write'
and keep writing until we run out of space with a 'out of space' error occurs
from the 'C' calls. I think the error was ENOSPC, 'No space left on device'. )
I understand that -if- the AFS client were to return an arbitrarily large size
number for the 'disk free' on them mapped drive, and the application writes
into a sub-folder, then that sub-folder may be an AFS volume that doesn't have
that 'disk space' available. In that case the application would lose data when
going over quota for the volume. So some decision was made to return 'zero
bytes available' on all drives mapped to the AFS root.
You get around the issue by mapping a drive directly to the AFS volume in which
you need to write to.
If you don't care about losing data, one solution is to 'symlink' the cell into
the C: drive, as follows...
C:\>mklink /d c:\afs \\afs\root.afs
A DIR of c:\ will then return what is available on your C: drive.
We ran the AFS client for years on Windows XP and it always returns 2 TB as
free on a mapped drive.
This is a VERY annoying problem.
I wish AFS would prevent you from writing more into a volume than the quota
size that you were allocated. In that case returning ENOSPC, 'No space left on
device' should be applicable.
Rodney
Rodney M. Dyer
Operations and Systems (Specialist)
Mosaic Computing Group
William States Lee College of Engineering
University of North Carolina at Charlotte
Email: rmd...@uncc.edu
Phone: (704)687-1942
Help Desk Line: (704)687-5080
FAX: (704)687-2352
Office: Cameron Hall, Room 232
-----Original Message-----
From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org] On
Behalf Of Jeffrey Altman
Sent: Saturday, October 19, 2013 10:27 PM
To: Ian Crowther; openafs-info@openafs.org
Subject: Re: [OpenAFS] not enough space in target directory
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
