Hi, I run into "this" frequently on my Win 7 (64-bit) laptop. I had a sense the problem might be related to changing networks and hibernation, but shamefully I haven't made any real effort to root cause it.
In my random attempts to deal with it, I found that reboots (usually more than one) helped. It hadn't occurred to me to try flush the cache, I will remember to try it next time I see this. Thanks, Matt ----- "Jeffrey Altman" <[email protected]> wrote: > On 11/25/2014 10:22 AM, Howard Jr, Russell A wrote: > > Since October, I’ve been doing upgrades and new installs of the > OpenAFS > > Client using 1.7.3200. We’ve recently encountered what appears to > be a > > cache-related bug in this version but I haven’t found a way to > reliably > > reproduce it. All clients are running Windows 8 x64 Enterprise as > the OS. > > > > When the error occurs, it presents itself by the user seeing the > > following message when trying to access any mapped AFS drives (“M” > in > > this case): > > > > M:\ is not accessible. > > > > The name of the file cannot be resolved by the system. > > This error can be generated from at least a thousand different > causes. > The Release Notes that ship with the client include debugging > instructions that will help you identify the cause of the problem. > > > In order to restore AFS access on the machine, I had to stop the > AFS > > Client service, remove the cache file, and restart the service. > > Stopping the service will leave the kernel in an inconsistent state > which can result in data corruption. A reboot of the system should > be > performed at the earliest opportunity. > > There are many "fs" commands for manipulating the state of the cache > manager > > fs checkservers > fs checkvolumes > fs flush > fs flushvolume > fs flushall > > or examining the state > > fs examine > fs memdump > > That should be used in preference to stopping the service. > > In particular, if you believe the problem is related to bad state > information being stored in the AFSCache file then the "fs flushall" > command would invalidate all of it without a service stop. > > This is the first report I have heard about it. -- Matt Benjamin CohortFS, LLC. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://cohortfs.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
