XSAN, Veritas netbackup and disappearing ._ resource fork files

I am doing some testing of backups of XSAN volumes (using Veritas Netbackup). I am running XSAN 1.4.1 on MacOSX 10.4.9 I found that doing a full restore of a directory tree was losing the ._ files that represented resource forks. The particular application we are using embeds metadata into the resource fork of a file, and on XSAN this gets created as a separate file with the prefix ._ followed by the file name (e.g. file 'abc' has resource fork '._abc'). More investigation revealed that some files still had their ._ resource forks. In particular, files with names starting with '+'. More testing today has discovered the cause: On XSAN, if I rename a file, and if it has a ._ resource fork that gets renamed too. So far so good, although this isn't exactly standard behaviour! If there is already a ._ file of the target name, that is DELETED whether the file has a ._ resource fork or not - in effect an absent resource fork overwrites the ._ file - probably to avoid a bogus resource fork becoming attached. See below: [code] xs04:/Volumes/XSAN admin$ ls -al total 65568 drwxr-xr-x 2 admin ingestgr 2048 Feb 16 17:59 . drwxrwx--- 51 admin ingestgr 12288 May 21 16:18 .. xs04:/Volumes/XSAN admin$ touch ._a xs04:/Volumes/XSAN admin$ touch b xs04:/Volumes/XSAN admin$ ls -al total 65568 drwxr-xr-x 4 admin ingestgr 2048 May 21 16:57 . drwxrwx--- 51 admin ingestgr 12288 May 21 16:18 .. -rw-r--r-- 1 admin ingestgr 0 May 21 16:57 ._a -rw-r--r-- 1 admin ingestgr 0 May 21 16:57 b xs04:/Volumes/XSAN admin$ mv b a xs04:/Volumes/XSAN admin$ ls -al total 65568 drwxr-xr-x 3 admin ingestgr 2048 May 21 16:57 . drwxrwx--- 51 admin ingestgr 12288 May 21 16:18 .. -rw-r--r-- 1 admin ingestgr 0 May 21 16:57 a [/code] This is not the behaviour on an HFS+ filesystem. With my restore, the files were being created in a temporary directory and then moved into the target directory. The files starting with "+" were backed up before the ._ files and then the regular files. Thus the regular + files were created followed by their ._ resource fork, but for other cases the ._ resource fork would be created and then shortly afterwards obliterated as the regular file is moved into place. Has anyone else encountered this problem and found a workaround? Thanks, David.