Archive for the ‘File service’ Category

DFS-Namespace creation with an simple xlm file

March 20, 2009 Leave a comment
Technorati Tags: ,,


last time i had a little problem with DFS-N (distributed file system namespace) under Windows Server 2008, but it was not really a problem. I was searching for an solution with that i can create many folders in an big DFS-N tree. But all this folders have non Link targets and i had no idea.

The first solution I found to create DFS-N folder without target-links was DFSMGMT.MSC. But i can only create folder one at a time. It’s not exactly brilliant.

The other possibility is to use DFSUTIL.  With DFSUTIL I can export and import DFS-Namespaces !

That is it, i have exported my temporary DFS-N and have an export file. The output file of the export is an XML file. After I have edit the export file, import it with DFSUTIL /import and well, now I can browse my new big DFS-Namespace tree.

Symbolic Link under SMB2 Protocol

March 11, 2009 Leave a comment


SMB2 Protocol – what is a Symbolic Link?

for an customer project I would learn, what is new in SMB2 and found this blog entry.

In Vista/Longhorn server, the file system (NTFS) will start supporting a new filesystem object (examples of existing filesystem objects are files, folders etc.). This new object is a symbolic link. Think of a symbolic link as a pointer to another file system object (it can be a file, folder, shortcut or another symbolic link). So then you ask how is that different from a short-cut (the .lnk file)?  Well, a shortcut will only work when used from within the Windows shell, it is a construct of the shell, and other apps don’t understand short-cuts. To other apps, short-cuts look just like a file. With symbolic links, this concept is taken and is implemented within the file system. Apps when they open a symbolic link will now open the target by default (i.e. what the link points to), unless they explicitly ask for the symbolic link itself to be opened. Note symbolic links are an NTFS feature.

Now why is this relevant to the SMB2 protocol? This is because, for symbolic links to behave correctly, they should be interpreted on the client side of a file sharing protocol (otherwise this can lead to security holes). SMB2 understands the concept of symbolic links and evaluates the links on the client. This is the support that is added in SMB2.0


Categories: File service