Christian, Feel free to make noise wherever you wish but the reality is that when Microsoft has a the choice to make between developers spending time on the Shell and addressing bugs with its own tools (SkyDrive, ReFS, etc) or those of third party products, Microsoft is going to focus on its own stuff unless an entity (or an effected community) is paying them sufficient money to make it worthwhile. In the end it requires multiple paid support contract reports to raise the profile of the bug enough that it will be fixed.
Jeffrey Altman On 10/14/2013 9:33 AM, Christian wrote: > Jeffrey, > > thanks for the hint. I had been blaming this on myself, suspecting > something was not correctly configured. > > Now I have a really dumb question: is this one of the things you can > only do with a support contract? Or via connect.microsoft.com? Is there > any additional information I should submit? We are a University in > Germany and run Windows 7 Enterprise... > > Best, > > Christian > > Am 05.10.2013 02:18, schrieb Jeffrey Altman: >> 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 >> > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info >
smime.p7s
Description: S/MIME Cryptographic Signature
