cancel
Showing results for 
Search instead for 
Did you mean: 

CIFS and .tmp file creation

npasquetto
Champ in-the-making
Champ in-the-making
Hi, on our production environment (Alfresco 4.2) we have a problem on the <strong>CIFS shares</strong>: when a user saves a file using office (2010), in the same folder create <strong>a file with the extension ".tmp"</strong>.
We have other shares (not exposed through Alfresco, but as a normal network disks) on which, for the same utilities, <strong>not verify this problem</strong>.
We tested completely <strong>disabling the antivirus</strong> and nothing has changed (the .tmp are created anyway).


From what can be causing this problem?


Thank you all.
5 REPLIES 5

afaust
Legendary Innovator
Legendary Innovator
Hello,

the .tmp files are created by Office itself and should be cleaned up by Office. If the client fails to do so, these files will remain. Make sure you don't have a policy / rule that removes the ownership / delete permission on those temporary files for the user working with them or the client will not be able to remove them.

Regards
Axel

npasquetto
Champ in-the-making
Champ in-the-making
Hello Axel, thank you very much for your reply.
There are problems of policy/roles because <strong>the user is able to manually delete the file</strong>.

Indeed, the problem occurs only with that client (Office) but also occurs <strong>only on the Alfresco CIFS share</strong>.

Hi npasquetto,

This is a know issue.  I believe this is the JIRA issue on the matter: https://issues.alfresco.com/jira/browse/ALF-13815

Apparently its fixed in the head.  Probably can be tested by downloading 4.2d nightly.

Ben

Hi Ben, thank you for the reply.
We <strong>already have a 4.2d nightly (downloaded the 7 of Febraury) installed</strong>, because in the 4.2c there was another kind of promblem with CIFS.

But probably isn't a locking problem, because <strong>the user is able do manually delete the file</strong>.

Anyway, for tests, we can try the latest nightly build.

Hello to everyone, from tests carried out on a nightly build more recent (13/03) it seems that <strong>the problem is not present anymore</strong>.

Thank you all for your support.