As I said, the AFS redirector is reporting the over quota condition as part of the response to the CloseHandle() call. Explorer does not call FlushFile() before CloseHandle() knowing that CloseHandle() will flush the file to disk.
I will think about this some more and see if I can come up with something. The problem is that Windows is storing the data into the Windows page cache prior to the AFS redirector being asked to allocate space. Once we are asked, we fail it but by then it is too late. On 4/5/2012 8:34 AM, Lars Schimmer wrote: > On 2012-04-05 13:15, Jeffrey Altman wrote: >> At the moment the AFS Redirector does not implement the Windows >> Volume Quota Service interface. Therefore, Windows has no >> knowledge of per user quotas. > >> The behavior you are seeing is due to the fact that Windows is >> copying the entire file into the Windows page cache and it is only >> being sent to \\AFS when the file is closed. At that point the AFS >> redirector does report the over quota error but the application >> ignores it. In this respect the Windows client is now more like >> the UNIX client. > >> Adding support for the Volume Quota Service interface is a feature >> that I would like to see implemented. However, doing so is >> non-trivial. It requires mapping AFS PTS IDs to Windows SIDs for >> users that may access the file system after the quota information >> was reported to the system. > > Thanks > > But until that is implemented, the result is to have always > "unreachable" quotas on volumes for users not to loose data on copy > actions? Do I see it right? > > But: isn´t there any simple, quick hack workaround possible for simple > explorer copy action to tell: file did not arrive 100% at server? > > >> Jeffrey Altman > > MfG, > Lars Schimmer > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info
signature.asc
Description: OpenPGP digital signature
