Jeff, thanks for your kind response.
I turned of afs tracing.
> fs trace -on
Then I went through the afs volume and started renaming folders.
When I hit a folder where the rename operation was prevent, I clicked on
the 'try again' option a couple of times. Then I cancelled to operation,
went to another folder, succesfully renamed it. Then I went back to the
folder that had the denial -- and it renamed successfully.
I then did an fs trace dump
> fs trace -dump > afs-trace.log
But the log file is empty. So, I'm guessing that afs did not see any
errors.
I also scanned the windows event logs and could not see anything that
seemed related to an afs error, or even a file system error. There are
errors about the volume shadow copy service which concern me but doubt they
are related. The time of the errors I think coincides with the failed
folder renames but I not really sure. Here's the error:
Volume Shadow Copy Service error: The I/O writes cannot be held during the
shadow copy creation period on volume
\\?\Volume{ced7ad8f-db91-11df-aa8e-806e6f6e6963}\. The volume index in the
shadow copy set is 0. Error details: Open[0x00000000, The operation
completed successfully.
], Flush[0x00000000, The operation completed successfully.
], Release[0x80042314, The shadow copy provider timed out while holding
writes to the volume being shadow copied. This is probably due to excessive
activity on the volume by an application or a system service. Try again
later when activity on the volume is reduced.
], OnRun[0x00000000, The operation completed successfully.
].
Not sure if that is a complete waste of time.
On Wed, Jan 2, 2013 at 4:58 PM, Jeffrey Altman <[email protected]
> wrote:
> On 1/2/2013 6:36 PM, David Bear wrote:
> > We are using oepnafs version 1.7.XXX varous sub-versions and noted that
> > when we attempt to move or rename folders or files that we will on
> > occasion get the message:
> >
> > 'folder in use error'
> > 'the action cant be completed becuase the folder or file in it is open
> > in another program'
> >
> > This error persists for random amounts of time across different volumes
> > and different clients. Eventually, the error vanishes and the rename
> > operation completes.
> >
> > We are fairly certain that users do NOT have files open underneath these
> > folders open. But we have not test this. The users report that they do
> > not have the files open.
> >
> > The error seems to be that openafs randomly thinks a file is locked...
> >
> > Any ideas?
>
> While I will not rule out a bug the following is true on Windows. Any
> application on the system that has a folder set as the current directory
> will prevent that folder and all folders in the path from
> being removed. This check is enforced by Windows not by the AFS service
> or file system drivers.
>
> If an AFS lock is held on the directory, that will be visible in the "fs
> trace" log data.
>
> Jeffrey Altman
>
>
>
--
David Bear
College of Public Programs at ASU
602-496-0424
