Three bugs (two serious) with .docx files on Mac OS X Server (ESET 6.0.14.0)

[stevemaser 2]

Full disclosure -- we are attempting to use Microsoft's SCEP 4.5.21.0 -- which is based on the ESET engine and discovered two bugs with it -- so we decided to check the current trial version of ESET to see if the two bugs are there -- and they are....

 

 

Using ESET 6.0.14.0 on Mac OSX 10.9.5 and 10.10.2 clients connecting to Mac OS X Server (both 10.9.5 and 10.10.2 server tested...)

 

SERIOUS BUG 1 -- Default install of ESET will delete saved Word 2011 .docx files on server when connected to server via SMB

 

To reproduce:

 

1)  Default installation of ESET on Mac 10.9.5/10.10.2 client.

2)  Client opens a .docx file (<filename.docx>) with Word 2011 (current version) on an OS X  server share (problem seems limited to .docx files -- not .doc files or .xlsx/.pptx files...)

3)  User attempts to save the file.   A dialog box pops up that says "There has been a network or file permission error.  The network connection may be lost. (<filename.docx)>

4)  This results in the original file being renamed to "Word Work File _L3.tmp" and a saved file named "Word Work File L_1.tmp" -- but the original <filename.docx> -- is completely gone.

 

WORKAROUND:

 

In ESET, if the following default check box is *disabled*:

Preferences --> Real-time Protection -- > Advanced Options --> Scan Options:  Advanced Heuristics

 

Then the user can open and save the .docx file without the original file being "deleted" and the two "Word Work File..."s created and left behind.

 

 

 

SERIOUS BUG 2 -- Word will SPOD if the above is attempted, but the server connection is made via AFP instead of SMB.

 

We attempted to reproduce the above bug on a 10.10.2 client by having the client connect to the server via AFP instead of SMB.   This has worse results.

 

In this case, the user goes to save the file, but the following happens:

 

1)  A "Word Work File D_.tmp" file is created on the server.

2)  Word goes into a SPOD -- and does not recover and must be force quit.   Which seems to still leave something locked on the system as it requires a hard shutdown to restart.

3)  After client restart, "Word Work File D_.tmp" on server is still flagged "in use" and can not be deleted by client.

 

WORKAROUND -- have not determined if there is one short of turning the RTF *off*.   Nor do I know if this is limited to .docx files (I just ran across this one right now while documenting the bug above...)

 

 

BUG 3 (not as serious)  -- Occasionally, server files can not be duplicated with default ESET settings (also when connected via SMB)

 

To reproduce

1)  Same default install of ESET, same clients, same server as above, but connecting via SCEP

2)  User goes to a server folder containing a number of files.

3)  User attempts to duplicate files on the server.  (Simple command-d duplicate)

4)  Occasionally, user will be unable to duplicate the file and the Finder shows a dialog box that says "The operation can't be completed because the item "<filename.docx>" is in use.

 

WORKAROUND:  subsequent attempts at duplicating the same file will work if the user tries again.  

 

or

 

Disable:   Preferences --> Real-time Protection -- > File Open 

 

None of these issues occur without ESET (or SCEP) installed.

 

These are all pretty terrible bugs, frankly, and are easily reproducible...

 

 

Is there anyone on the forum that can address any of these issues?

Edited February 9, 2015 by stevemaser

[stevemaser 2]

Why all these issues are associated with .docx files -- is probably a good question for Microsoft.   I tried a .doc file -- and could not reproduce any of the three problems (same with .xls/.xlsx and .ppt/.pptx files...)

 

Whatever the problem is with Word, ESET is not handling these files correctly and causing deleting/hanging/degradation.

Edited February 9, 2015 by stevemaser

[Peter Randziak 1,130]

Hello Steve,

 

we have similar issue reported and our Devs are looking into it.

Until we release fixed version, the only workaround is to set proper exclusions.

 

By the way do you have a ticket with your local support open?

 

We are sorry for the inconvenience caused by this issue.

 

P.R.

[Xocoa 0]

Hello,

We have the same issue here with ESET on OSX (various from 10.9.5 to 10.10.2) and an Ubuntu file server running samba 4.1.12

I noticed that if you make some changes in a docx with Open or LibreOffice it can be saved without problems AND then MS Word is able to use it and save it.

Once the docx is saved with Open or LibreOffice the content is the same but structure of the file is changed and I think more standard compliant.

[stevemaser 2]

Hello Steve,

 

we have similar issue reported and our Devs are looking into it.

Until we release fixed version, the only workaround is to set proper exclusions.

 

By the way do you have a ticket with your local support open?

 

We are sorry for the inconvenience caused by this issue.

 

P.R.

 

 

We have a ticket open with Microsoft about this behavior with SCEP 4.5.21.0 (since it's their branded version of ESET) -- as it seemingly only affects MS Word (at least the non-duplicate bugs do...)  

 

I did submit the above bugs to ESET support, but basically just got a "thanks.  don't call us, we'll call you" response to these bugs -- which was a bit disheartening.

 

 

ALSO -- FWIW -- I did try setting exclusions to .docx extensions -- but that made no difference (and I thought it would...)

 

I can not exclude the path as that would vary from end-user to end-user.

Edited February 24, 2015 by stevemaser