CIFS / Webclient file corruption after working copy update

[raphael]

Dear developers/users,

we have just faced the following situation here:
- we created an ods (OOo Calc) file in the CIFS share of Alfresco
- we worked on it for about one month (not much updates but some)
- one of our user tried to use it from the Web client and checked out a working copy of the document
- this same user checked back in a new version of the document and since then the file appears to be corrupted (at least OOo proposed to repair this "damaged file" and effectively repairs it) (both in CIFS and Webclient)
- we checked it out one more time and re-uploaded the file with a check in
- the file is now correctly visible from the web client but still corrupted in the CIFS although its last modification date reflects our last modifications.
- even after unmounting and re-mounting the share, the file still appears corrupted in cifs.

Other information:
- alfresco community 1.3 + NTLM passthru patch on a Debian GNU/Linux system
- access from ubuntu and debian hosts through CIFS and Firefox.

So, is there a cache mechanism in place for the CIFS share? Any way to force an update of such a cache? Anyone faced a corruption situation? What did we miss?

Any help welcome,
Raphaël

[gary_spencer]

Hi,

It does sound a bit odd. You could run md5sum against a local copy of the file and the CIFS server copy, see if the two values are the same. If you copy the file from the CIFS server then access it does it still have problems ?.

Are you using the smbfs or cifs filesystem when mounting the Alfresco share, ie. what mount command are you using ?.

Cheers

Gary

[konradpotocki]

Well… this seems to be a bit similar to my problem, described here:

http://forums.alfresco.com/viewtopic.php?t=3624

What's more, I have also got the problem of corrupted file on CIFS once. I have never reproduced it, but the corruption happened after the "Web" user modified an OpenOffice file and the "Samba" user tried to read it. The strange thing was that OO proposed the recovering and successfuly recovered the file.

[raphael]

Thanks for answers,

here are more details concerning this issue:

- I wasn't able to corrupt a .doc file but corruption can systematically be reproduced for .ods and .odt:

- create a test file named test.odt
- check it out (working copy in the current space, and download a version of the file for editing)
- modify your file and check it in with HTTP UPLOAD => the initial file is corrupted (size not the same and the md5sum consequently differs)

If you do the same thing with a .doc (even one generated with OOo) everything is ok.

IMPORTANT: if instead of uploading through HTTP while checking in the file, you choose to update from the copy in the repository ("Use copy in current space" option), then the file is not corrupted at all.

Another odd issue is that I must unmont and remount the CIFS filesystem from my linux box to see the effective changes (I mean, date and size of files are instantly updated after each change, but opening a file which was just updated opens the old version of it until I unmount/mount the CIFS share).

The exact command line used to mount the share is the following:
mount -t cifs //blabla/Alfresco ~/mnt/ged -o domain=xxx,user=yyy,pass=zzz,iocharset=utf8,uid=1234

Thanks, any help still welcome.
Raphaël
P.S. I'm gonna do more testing with a fresh install of both 1.3 and 1.4RC, but it requires some time.