Jeffrey, Hm. Sorry if I wasn't clear. I am not sure if we have a support contract or not. I am just a part-time sysadmin at a University institute. My main job is running a research group in physics. I hadn't been able to find out from the central IT people at the University level whether we have a support contract for Windows :-( so we probably don't...
Is there a way to find out whether one has a support contract? Christian Am 14.10.2013 15:59, schrieb Jeffrey Altman: > 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 >>>> OpenAFS-info@openafs.org >>>> https://lists.openafs.org/mailman/listinfo/openafs-info >>> >> >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info