If you have ever tried using Robocopy to copy the contents of a whole drive to a folder, you will find that the destination folder disappears or does not appear to have been created. Example:
robocopy m: \\backupserver\mybackup
robocopy m:\ \\backupserver\mybackup
(where 'mybackup' is a share)
Well obviously after watching the thing copy, the data went somewhere, yes you guessed it, its hidden and using ATTRIB will reveal it. Go to a command prompt, navigate to the parent folder and type:
attrib -s -h foldername
and the folder will come back. However, the real question is why does Robocopy do that?
Here is the skinny - The reason your target folder has the (S)ystem and (H)idden attributes set is... because your source does! Robocopy is faithfully copying those attributes. Wha! Wha! What! I hear you say... Well you cannot use ATTRIB to prove it either way, because if you are in a command prompt you cannot lift you current directory higher that the root of a drive. You cannot lift your current directory to the level of 'My Computer'. The fact is that the root of all drives has the (S)ystem and (H)idden flags set, but you usually cannot see that because 'My Computer' is a presentation created by explorer.exe, it is really quite an abstract concept.
As stated, since you cannot lift the current directory in a command prompt higher than root of the drive, you cannot use ATTRIB to prove this, but you can use Powershell.
Open Powershell and type:
or in my example:
and you will see an output like this:
Mode LastWriteTime Length Name
---- ------------- ------ ----
d--hs 10/11/2013 5:33 PM M:\
Note the (d)irectory, (h)idden, (s)ystem
So there you go - Powershell does not have a bug, it is copying the attributes faithfully. You just have to use ATTRIB afterwards to clean up.