Gary,

Thanks for the report. The reindex failed for a completely mundane reason: the archive data is damaged.

So the good news is that it didn't fail because of any weird "no such file" error.

The reindex detected an invalid record during its examination of the primary data file. Since this is on a networked volume, it's not unlikely that this was a transient data error. The simple test is to reindex again and see if the error occurs at the same position in the file.

It could also mean that something has overwritten or corrupted that archive data, in which case a repair is the only way to work around it.

James,

You are correct...no surprise.

When the Capture action to the archive stored on the SMB mount point fails, the archive is left damaged...and must be repaired first. This was automatically happening before...since I always ran a Verify action after the Capture failed...and the Verify fixed the archive's data component.

My error, in this case, was attempting to reindex of the archive before manually repairing it...(or running a Verify)...and it, therefore, failed, as you stated because the data was damaged by the Capture.

I repeated my steps...after first copying a clean archive to the SMB share...

1) Running a Capture...which failed.
2) Repairing the now damaged archive on the SMB share
3) Deleting all the .index files in the package
4) Reindexing the archive...which did work fine.
5) Trying another Capture...which failed.


So...at this point, I believe it is still only the Capture that has the issue to the SMB share.