[OpenAFS] issue with rename/copy/move and locks
David Bear
David.Bear@asu.edu
Wed, 2 Jan 2013 17:31:30 -0700
--f46d0401fe6ff75e9d04d2577be2
Content-Type: text/plain; charset=UTF-8
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 <jaltman@your-file-system.com
> 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
--f46d0401fe6ff75e9d04d2577be2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Jeff, thanks for your kind response.<div><br></div><div>I turned of afs tra=
cing. =C2=A0</div><div>> fs trace -on</div><div><br></div><div>Then I we=
nt through the afs volume and started renaming folders.</div><div><br></div=
><div>
When I hit a folder where the rename operation was prevent, I clicked on th=
e 'try again' option a couple of times. Then I cancelled to operati=
on, went to another folder, succesfully renamed it. Then I went back to the=
folder that had the denial -- and it renamed successfully.=C2=A0</div>
<div><br></div><div>I then did an fs trace dump</div><div>> fs trace -du=
mp > afs-trace.log</div><div><br></div><div>But the log file is empty. S=
o, I'm guessing that afs did not see any errors.=C2=A0</div><div><br></=
div>
<div>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 erro=
rs 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 r=
enames but I not really sure. Here's the error:</div>
<div><br></div><div><div>Volume Shadow Copy Service error: The I/O writes c=
annot be held during the shadow copy creation period on volume \\?\Volume{c=
ed7ad8f-db91-11df-aa8e-806e6f6e6963}\. The volume index in the shadow copy =
set is 0. Error details: Open[0x00000000, The operation completed successfu=
lly.</div>
<div>], Flush[0x00000000, The operation completed successfully.</div><div>]=
, Release[0x80042314, The shadow copy provider timed out while holding writ=
es to the volume being shadow copied. This is probably due to excessive act=
ivity on the volume by an application or a system service. Try again later =
when activity on the volume is reduced.</div>
<div>], OnRun[0x00000000, The operation completed successfully.</div><div>]=
.=C2=A0</div><div><br></div><div>Not sure if that is a complete waste of ti=
me.=C2=A0</div><br><div class=3D"gmail_quote">On Wed, Jan 2, 2013 at 4:58 P=
M, Jeffrey Altman <span dir=3D"ltr"><<a href=3D"mailto:jaltman@your-file=
-system.com" target=3D"_blank">jaltman@your-file-system.com</a>></span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 1=
/2/2013 6:36 PM, David Bear wrote:<br>
> We are using oepnafs version 1.7.XXX varous sub-versions and noted tha=
t<br>
> when we attempt to move or rename folders or files that we will on<br>
> occasion get the message:<br>
><br>
> 'folder in use error'<br>
> 'the action cant be completed becuase the folder or file in it is =
open<br>
> in another program'<br>
><br>
> This error persists for random amounts of time across different volume=
s<br>
> and different clients. Eventually, the error vanishes and the rename<b=
r>
> operation completes.<br>
><br>
> We are fairly certain that users do NOT have files open underneath the=
se<br>
> folders open. But we have not test this. The users report that they do=
<br>
> not have the files open.<br>
><br>
> The error seems to be that openafs randomly thinks a file is locked...=
<br>
><br>
> Any ideas?<br>
<br>
</div></div>While I will not rule out a bug the following is true on Window=
s. =C2=A0Any<br>
application on the system that has a folder set as the current directory<br=
>
will prevent that folder and all folders in the path from<br>
being removed. =C2=A0This check is enforced by Windows not by the AFS servi=
ce<br>
or file system drivers.<br>
<br>
If an AFS lock is held on the directory, that will be visible in the "=
fs<br>
trace" log data.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jeffrey Altman<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>David Bear<br>College of Public Programs at ASU<br>602-496-0424
</div>
--f46d0401fe6ff75e9d04d2577be2--