[OpenAFS] possible microsoft excel 2010 corruption issue on openafs volumes

[Jonathan Nilsson]

--f46d0444ef2d66f94404b3893768
Content-Type: text/plain; charset=ISO-8859-1

Hello,

We've had some strange file corruption and missing data issues with
Microsoft Excel 2010 on a Windows 7 OpenAFS 1.5.78 client.

1) A user creates an Excel file on their local drive, then copies it to an
AFS RW mount point (via mapped network drive).
2) several clients read the file (no changes made)
3) at some point the file is no longer able to be opened, or it opens but
warns of corruption and missing data

When I recover the file from the backup on the day of the file's
modification timestamp, the restored file is fine. Curiously, the restored
file appears identical to the corrupted file: the file size (bytes) and
timestamp are identical.

The fileservers housing volumes where this has happened are:
 CentOS 6.0 2.6.32-71.29.1.el6.x86_64 with OpenAFS 1.6.0
 RHEL 6.1 2.6.32-131.2.1.el6.x86_64 with OpenAFS 1.4.14

We have upgraded the client to OpenAFS 1.7.2 (we did this just before the
1.7.3 announcement) hoping to fix the issue if it is a bug... Is there any
known issue with 1.5.78 client that could have caused corruption like this?

-- 
Jonathan.Nilsson at uci dot edu
Social Sciences Computing Services
SSPB 1265 | 949.824.1536

--f46d0444ef2d66f94404b3893768
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>We&#39;ve had some strange file corruption and mi=
ssing data issues with Microsoft Excel 2010 on a Windows 7 OpenAFS 1.5.78 c=
lient.</div><div><br></div><div>1) A user creates an Excel file on their lo=
cal drive, then copies it to an AFS RW mount point (via mapped network driv=
e).</div>

<div>2) several clients read the file (no changes made)</div><div>3) at som=
e point the file is no longer able to be opened, or it opens but warns of c=
orruption and missing data</div><div><br></div><div>When I recover the file=
 from the backup on the day of the file&#39;s modification timestamp, the r=
estored file is fine. Curiously, the restored file appears identical to the=
 corrupted file: the file size (bytes) and timestamp are identical.</div>

<div><br></div><div>The fileservers housing volumes where this has happened=
 are:</div><div>=A0CentOS 6.0 2.6.32-71.29.1.el6.x86_64 with OpenAFS 1.6.0<=
/div><div>=A0RHEL 6.1 2.6.32-131.2.1.el6.x86_64 with OpenAFS 1.4.14</div><d=
iv>

<br></div><div>We have upgraded the client to OpenAFS 1.7.2 (we did this ju=
st before the 1.7.3 announcement) hoping to fix the issue if it is a bug...=
=A0Is there any known issue with 1.5.78 client that could have caused corru=
ption like this?</div>

<div><div><br></div>-- <br><div><font face=3D"&#39;courier new&#39;, monosp=
ace">Jonathan.Nilsson at uci dot edu</font></div><div><font face=3D"&#39;co=
urier new&#39;, monospace">Social Sciences Computing Services</font></div>
<div>
<span style=3D"font-family:&#39;courier new&#39;, monospace">SSPB 1265 | 94=
9.824.1536</span></div><br>
</div>

--f46d0444ef2d66f94404b3893768--