Video Screencast Help

Problems accessing archived items

Created: 18 Dec 2013 • Updated: 14 Jan 2014 | 8 comments
ChayDouglas's picture
This issue has been solved. See solution.

Hi All,

I have a deep rooted issue that I just can't seem to get to the bottom of.

I initially came across this issue as I am in a project of decomissioning EV for a customer. I am exporting files from FSA, firstly replacing the placeholders back to the file servers using fsautility -b and secondly exporting the entire archive to a scratch storage using fsautility -t -d.

I have came across a small number of files that throw up errors during the export to the scratch storage. The original event id is 41145.

Restoring of file [filename] failed for destination [destination]

Additional info: Error HRESULT E_FAIL has been returned from a call to a COM component.

Along with a 6882 event id:

Unable to complete retrieval request

Reason: Decompression failed. The number of bytes actually read does not match the number of bytes expected. (0xc004713d)

Both these errors come from the File Server Archive Manager.

These errors also lead me on to another underlying issue. I find the file(s) causing the issue and drill down to them using Archive Explorer. When I double click on the item it comes up with "GetOnlineAttachmentFileSize 0x80004005"

It also gives the event ids: 6882 and 6287 when trying to open the file.

The 6287 event id is a Web Application (WP) warning stating:

Unable to fetch item from [Server]
Reason: Unspecified error (0x80004005)
Reference: [GOAFS]

I have ran a dtrace against w3wp, storagerestore, storageonlineopns, storagemanagement, storagefilewatch, storagecrawler and storagearchive and recreated the issue when trying to open via archive explorer.

The DTRACE is attached.

I am most concerned about the line:

592 11:52:04.917 [4524] (StorageOnlineOpns) <4564> EV:L {CZlibCompressor::LoadInputBuffer:#381} Zero bytes read from the stream, normally indicating end of stream (or a read problem under heavy load).

I have tried searching each issue one-by-one, but I feel like I'm chasing my tail with this one. Any help would be appreciated.


Operating Systems:

Comments 8 CommentsJump to latest comment

Rob.Wilcox's picture

I'd personally recommend going to Symantec Support with something like this.

ChayDouglas's picture

The items are from 2006 and when restored will no doubtedly just be deleted straight away! So I'm not too fussed to resolve a handful of items out of 15 Million. But just incase 1 of them could be important (unlikely) I thought I'd ask here to see if anyone had any ideas.

I have seen the "The number of bytes actually read does not match the number of bytes expected" message before with another customer but can't, for the love of me, think of what it was down to. And for some reason I can't seem to find any information on that in the forum, where I'm sure I had seen it before.

ChayDouglas's picture

So, If I search the problem files using the search within the VAC and try to open there, I get prompted for credentials... but entering the VSA credentials does not resolve the problem...

ChayDouglas's picture

No, not yet.

I am back on site on Monday.

I will attempt to recall them using EVSVR interactive. If that fails, I am happy to class them as corrupt data.


plaudone's picture

From the log it looks like it is an issue reading the DVSSP.  You may be able to get more information when trying to dump the saveset using EVSVR.  

If found to be corrupt then you could run EVSVR > Verfiy > ArchiveObjects > SavesetValid to check items. The ones that cannot be recombined can either be deleted manually or Support has a script that can be run to remove those items from the DB and indexes. 

ChayDouglas's picture

Hi Plaudone,

You appear to be correct in your diagnosis.

I have attached the EVSVR interactive Dumpsaveset data that confirms that the item is corrupt.


AttachmentSize 2.09 MB
plaudone's picture


I checked the DVSSP with an internal tool and it does seem to be corrupt as I am unable to check it properly.  The VSDBRecords.xml file contains information on the file from the DB's and indicates the file is OR105CO2Mk4REWORKCast Former Set29-08-06L.doc.  

I would suggest running the EVSVR > Verfiy > ArchiveObjects > SavesetValid operation to see how many items total are affected by this issue.  The only way to recover those files would be from backup of the original files from the file server.  If you want to delete them from the archive you can do so manually using Archive Explorer or contact Support for the script to remove them from the database.