Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

DFS Deleteing reparse point files

Created: 31 Oct 2012 • Updated: 09 Dec 2012 | 8 comments
bawright's picture
This issue has been solved. See solution.

Hi There

We have reparse point files on our dfs share I know that these files don't get replicated which I don't care about. However these are been deleted from the share which I do care about.

Does anyone know why these files are been deleting and maybe how can prevent this from happen?

Cheers,

Brett

 

Comments 8 CommentsJump to latest comment

TonySterling's picture

hiya,

What product are you using that you think is deleting the reparse points?

bawright's picture

I have a feeling that DFS is deleting the files.

As these files don't exsit on the other DFS servers. This was working fine for ages and now it only just started deleting the files.

Enterprise Vault FSA..

Jeff Shotton's picture

So this isn't something like storage expiry and orphaned placeholder cleanup?

Do the items still exist in archive explorer?

Files containing reparsepoints should be replicated, but as a useless stub file as the reparsepoint will not be carried over, which is why they are not supported: see http://technet.microsoft.com/en-us/library/cc77323...

from the article:

The following file attribute values also trigger replication, although they cannot be set by using the SetFileAttributes function (use the GetFileAttributes function to view the attribute values).

FILE_ATTRIBUTE_REPARSE_POINT
 

Note
DFS Replication does not replicate reparse point attribute values unless the reparse tag is IO_REPARSE_TAG_SYMLINK. Files with the IO_REPARSE_TAG_DEDUP, IO_REPARSE_TAG_SIS or IO_REPARSE_TAG_HSM reparse tags are replicated as normal files. However, the reparse tag and reparse data buffers are not replicated to other servers because the reparse point only works on the local system.

 

Regards,

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

bawright's picture

I can still see the files in the archive explorer.

Also from what I can see the policy retention is set for forever and I don't have delete orphaned shortcuts setup.

Cheers,

Brett

Jeff Shotton's picture

Then you are going to have to use some sort of monitoring tool, such as processmonitor to filter on file deletes to figure out what is stripping placeholders (it might not have anything to do with EV, so a dtrace would be fairly useless)

http://technet.microsoft.com/en-gb/sysinternals/bb...

Make sure you choose your filters carefully since this can log a LOT of information.

Additionally you might be interested in using FSAUtility, which is detailed in the utilities guide, and can recreate missing placeholders.Not sure which version you are on, so here is the documentation master link. Click through to the version you are on, and look for 'utilities guide'

http://www.symantec.com/docs/DOC2200

or just see

http://www.symantec.com/docs/HOWTO37834 which talks about the option and assumes you know the tool

Regards,

Jeff

 

 

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

bawright's picture

OK I restore a placeholder using the FSAUtily and monitored the file for 2 days use procmon and looks like that DFSRs.exe has deleted/moved to D:\System Volume Information\DFSR\Private\

any ideas?

Cheers,

Brett

bawright's picture

Also I've had a look through the DFS log files and looks like the remote verison is dominating the local verison which I don't get because the placeholder doesn't exist on the remote server..

Jeff Shotton's picture

Interesting.

*maybe* this explains it

http://technet.microsoft.com/en-us/library/cc72589...

specifically, the text:

"When receiving files from the primary member during initial replication, if a receiving member contains files that are not present on the primary member, those files are moved to their respective DfsrPrivate\PreExisting folder. If a file is identical to a file on the primary member, the file is not replicated. If the version of a file on the receiving member is different from the primary member’s version, the receiving member's version is moved to the Conflict and Deleted folder and remote differential compression (RDC) can be used to download only the changed blocks. To avoid conflicts, do not make changes to files in the replicated folder on non-primary members until initial replication completes."

So maybe it is viewing it as a conflict and simply removing the file

I think to be honest you would need to ask on the Microsoft forums as to why DFS is removing the data though.

Regards,

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

SOLUTION