11-06-2014 06:16 AM
Hi everyone, I've got a curious scenario at the moment. I am trying to do a file restore - easy enough - fsautility -t -s \\specify path here
When the command initites, it builds a list of files to restore, says 'File restore operation has started' and 'XML file generated'
The XML file shows folders/files being walked, but not every single 'Last File Processed' is populated
You go to the source path, and the shortcuts remain - no restores
However, if you add a destination to the command and pipe the restore to a seperate folder/destination, the files restore?
The files that have been archived are for the telephony recording system RedBox, so the files are proprietary - called .frame files
EV doesn't seem to have had any trouble archiving them, but when you try and doubleclick restore, or restore from Archive Explorer the retore fails with 'Can't open file - make sure disk is in the drive'
But like I said, FSAUtility restore to an alternative location works
Does anyone have any ideas?
Solved! Go to Solution.
11-07-2014 08:42 AM
The alternate location would work as there are no files to overwrite and the -f switch would not be needed. The -f switch would be need to overwrite the PH files.
Also, if unable to get the file out of the archive from the file server then that could be another issue. Possibly the filter driver and service are not communicating properly.
11-06-2014 08:56 AM
i searched for the error you're getting about "make sure disk is in the drive" and came across some old posts. can you have a look through them and see if there's anything that might help?
https://www-secure.symantec.com/connect/forums/file-retrieval-problem
https://www-secure.symantec.com/connect/forums/certain-archived-file-types-will-not-open
11-07-2014 01:13 AM
Hi Andrew, thanks for your reply. I'm less concerned about the 'Can't open file - make sure disk is in the drive' message because this is a propietary file format which will not have a valid default program set to open it
What I'm most confused about is why I can restore to any alternative location I specify in the -d switch, but not back to the original location
I sense an escalation to symantec on the horizon.....
11-07-2014 04:29 AM
Hi EVSpinner,
When you run the restore to the original location are you using the -f switch? This will overwrite existing files whether they are shortcuts or full files.
A Dtrace of FSAUtility may also show some additional information.
11-07-2014 07:07 AM
Not -f but -t -s which I understood to be restore all items (-t) in specific path (s)
-f - Interesting idea, but doesn't explain the behaviour. Did lots of DTrace FSAutility, FsaArchMgr but omes back clean - no errors
Logging with Symantec,and will post back solution for future reference
11-07-2014 08:42 AM
The alternate location would work as there are no files to overwrite and the -f switch would not be needed. The -f switch would be need to overwrite the PH files.
Also, if unable to get the file out of the archive from the file server then that could be another issue. Possibly the filter driver and service are not communicating properly.
11-10-2014 08:46 AM
Nailed it Plaudone, nice one
-f is the solution
cheers
11-10-2014 10:21 AM
Great! Glad that it is resolved.