We have EV 11.0.1 CHF5, with mailbox archiving and file server.
When, for any reason, the EV services in the EV server are down, a reboot for instance, users can still recall archive files with a copy operation. The destination files are unusable, because they are not really recalled from archive.
How can I prevent this from happening?
Typically an open or copy/move should not be allowed as the file system will request the data in the file and the call is made to the EV server using the Placeholder Serivice on the file server(Windows). Without the data the operation should fail. There should be an event on the file server, if a recall was attempted and failed, in the Enterprise Vault Event Viewer log.
Is the file server Windows?
What are the attributes on the file when it is copied?
Just tried again now. Stopped the EV services, went to a network share, and copied a folder (TEMP). Got some errors and it did not copied all the files, but strangely some did!
Yes I have logs in Enterprise Vault Event Viewer log with the errors, including the error of the file that copied (aca.cer).
It's a Windows Server 2012 R2, and the attributes are equal on both files, except for the criation time.
I've attached a image with the original file (left) and the copied file (right).
The item looks to only have an A attribute. For the items to be FSA Placeholders they should have the attributes APLO or PLO if they have been backed up. If the items do not have the P(Sparse), L(Reparse), O(Offline) then they would not appear to be placeholders.
Do the errors in the event log correspond to the items that did not move?
You are right, other itens that were not copied do have the APLO attributes.
When I have users that report they cannot open files, and investigating the issue, I found that the files were recently created. Questining the user I found that they copied them from another place, that were previously archived.
My guess was that the EV archive was not available at the time, but allowed the users to copy the files, but without data in them.
I tried to replicate the problem, and thats the example I was using with the TEMP folder.
Any ideia what can cause this copy files without data?
If EV was not available the copy should not have been allowed as the data requested by the file system would not be available. I have seen when using robocopy it will not wait for the data and move/copy a file which will end up being corrupt at times. When using Explorer I have not seen the copy be allowed.
Would really have to know if the file was a valid PH to begin with on the source. It would have had those attributes.