Thread Subject: addpath and reatoredefaultpath with UNC

I use 'windows XP mode' to create x32 bit matlab standalone executibles sometimes.
I've noticed a strange bug addpath() for UNC-shared host machine folders may randomly fail.

To test this, I've used folowing scipt:

------------------------------------------------------------------------------------------------
n1=10;
n2=10;

for i=1:n1
    for j=1:n2
        mkdir( [cd '\' num2str(i) '\' num2str(j)]);
    end
end
    
------------------------------------------------------------------------------------------------
n1=10;
n2=10;

for i=1:n1
    for j=1:n2
       addpath( [cd '\' num2str(i) '\' num2str(j)]);
    end
end

------------------------------------------------------------------------------------------------
All is OK with 'normal' UNC folder (another PC) .

however, 'restoredefaultpath' fails:

>> restoredefaultpath
Warning: DOS programs may not execute correctly when the current directory is a UNC pathname.
> In restoredefaultpath at 35
Warning: Name is nonexistent or not a directory: "\\Wl-500w\disc3_1\temp"
“Є § ­­л© Їгвм Ўл« ЁбЇ®«м§®ў ­ ЇаЁ § ЇгбЄҐ CMD.EXE ў Є зҐб⢥ ⥪г饩 Ї ЇЄЁ.
CMD.EXE ­Ґ Ї®¤¤Ґа¦Ёў Ґв ЇгвЁ UNC. Џ® 㬮«з ­Ёо ўлЎа ­  бЁб⥬­ п Ї ЇЄ  Windows.
C:\Program Files\MATLAB\R2010b\toolbox\matlab\audiovideo.

================================================
Things get worse when I try to do the same with shared with XP mode 'integration features'. This time addpath fails....

>> add_folders2path
Warning: Directory access failure: \\tsclient\F\Igor\Documents\MATLAB\Test_projects\pathset_UNC\4\8.
> In path at 110
  In addpath at 87
  In add_folders2path at 6
<.....>

all later folders failed.

And here starts the most interesting part.... After this script I can't access \\tsclient\F even with file explorer. The only way to gain access back is to exit matlab - it'll be OK again immidiately.
================================================

I still can access my host machine's folders with common network-shared folders, like
\\G73jw\CTemp\2\. This works OK.... So, workaround is quite easy... Yet, the bug seems interesting....