cancel
Showing results for 
Search instead for 
Did you mean: 

Moving place holders issue

Sortid
Level 6

Hi, I'm using EV 2007 SP4.  We installed a new file cluster on x64 and are in the process of making this the new file server.  We have copied over all non-archived items and are now moving the archived items using FSAUTIL -m.  Originally there were 300,000 entries in the index, and after the util has run there is now 240,000 entires in the new index for the new archive point.  That means the move missed 60,000 files.  I have looked at the xml file that gets generated, there's about 200 files that errored due to being corrupt.  I then reran the move and took a dtrace.  It looks like the fsautility cannot move files that have long filenames (over 260 characters).  Although these files can be accessed from the file server directory structure, e.g. H:\data\..., they can't be accessed via the UNC path that fsautil uses, as this is pushes the file path to over 260 characters.

 

We are already archiving the new server, so I can't do a restore of archived files and copy those over, as this could over-write the placeholder files on the new server and I want to avoid that (this causes other issues). 

 

We have moved one file share, the smallest we had, out of about 10.  Hate to think how many files will be skipped when we attempt this on larger volumes.

 

Has anyone experienced this before?  How did you get around it?

 

Thanks.

4 REPLIES 4

Chris_Harrison
Level 5
Employee
We have had issues before in the past where FSAUtility has run into difficulties with long folder paths, however I'm not aware of any outstanding defects on this issue. I'd suggest logging a Support call and going through it with them.

Sortid
Level 6

I reran the move with dtrace logging on brief.  It came up with about 80 files which it didn't move.  Some of those had long file names, over 260 characters.  Others had 170, and I can fully access these files via UNC.  It's these ones I'm now curious about.  The error produced is:

 

83332 11:51:16.137  [10312] (FSAUtility) <9748> EV-H {MovePlaceHolderNormal.ProcessFile} Exception: Error checking if file: \\UNC path to file\filename is a placeholder file. Info:Error reading information for the file \\UNC path to file\filename. This file will not be moved. Diag: Type:KVS.EnterpriseVault.FileServerArchive.PlaceholderDetectionException ST:   at KVS.EnterpriseVault.FileServerArchive.WindowsNTFSVolume.IsFileAPlaceholder(Volume volume, VaultFileInfo fileInfo, String& itemUrl, String& retentioncategoryEid, DateTime& archiveDate, DateTime& modifiedDate)|   at KVS.EnterpriseVault.FSARestore.MovePlaceHolderNormal.ProcessFile(VaultFileInfo file)

 

I will log with Symantec formally.  In the meantime, any ideas?

Thanks,

Cam

Chris_Harrison
Level 5
Employee
Do the files that error have the offline attribute?

Sortid
Level 6

Yes they do have the offline file attribute.  This prompted me to double check the archiving log for that volume.  The files in question are generating the Element Not Found error.  We've had a few of these where users overwrite placeholders with real files of the same name which causes this error and archiving of them to stop.  We have had to run the offlinefiles.exe command across many files in the system to remove the attribute so archiving of these files can continue.  It looks like this process was not done before we did the copy over.  This is the case for the long file named files as well. 

 

I will look to remove the offline attribute and copy over manually.

 

Thanks for your help, you pointed me in the right direction.  I'll see what Symantec have to say about the discrepencies in the index files.