File a bug report with Microsoft if the problem is experienced when using the explorer shell or applications relying upon the shell api for file access.
This is a known bug in the explorer shell and Microsoft has been working on it for more than six months. As with all Windows bugs, a fix is prioritized based upon the number of complaints received from paying support customers. Jeffrey Altman On 10/4/2013 6:36 PM, Christian wrote: > All, > > we are seeing some weird issues with the windows client (1.7.26, but hat > also seen that with previous 1.7 versions). Often, when attempting to > write data, my users get a popup box complaining about insufficient > space in the target directory. In those cases, writing the data to the > RW path (.cell.name) instead works just fine. Note that the volumes > which are being accessed in those cases do NOT have RO replicas, just > some of the volumes from which they are mounted. Write access just fails > intermittently when accessed through a path which contains OTHER > replicated volumes. > > So, for example, say that the volume "users" containing the mount points > for the individual user volumes is replicated. Then write access to > /afs/our.cell/users/joe.user will fail intermittently, while writing to > /afs/.our.cell/users/joe.user always works. We use dynroot and SRV records. > > I have read the debugging instructions, but I am a little unsure about > how we should proceed here. What should I do? Try fs trace? > > Thanks, > > Christian > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info
smime.p7s
Description: S/MIME Cryptographic Signature
