I've now come across a situation at work where I need to copy massive amounts of nested folders from one server to another and along with the copy take across any network security permissions / shares. Probably looking to shift around 5 x 80-120Gb lots of data in total in the planned move.
Ideally I'd map drives on my PC and use DO to do the job (if it can) between the machines.
Can DO do this at all? If so it will save us investing a lot of money in an application like Secure Copy which I've been advised can do the job.
Opus should be able to do that, provided your account has the right permissions to copy the file permissions over, at least.
You'll want to turn on Preferences / File Operations / Copy Attributes / Copy security permissions, or create a special toolbar button which runs the Copy command with arguments that turn it on for that command. (Depends whether you want it to be the normal behaviour, or just the behaviour when you click a special button.)
Give it a try on some test files first to make sure it does what you want before leaving the whole 120GB to copy.
FWIW, I think the xcopy DOS command built-into Windows can also do this, if you find Opus doesn't quite do what you want. One or the other should get you there.
I opened the source (\SERVER04\e$) and destination (\SERVER-BRI11\d$) drives on the two servers directly within DO after turning on the option (as can be seen right hand side).
The source server SERVER04 shows that the 'Chrisk_Projects' folder should be read / writeable by Chris Knight only, for example Authenticated Users are denied access.
The folder when copied onto the destination SERVER-BRI11 has authenticated users having full access and there are no special security rights for Chris Knight.
So I'm either doing something wrong or I've found a bug?
Where do the Chris Knight permissions on server04 come from? If they're inherited from the parent folder then the copied file won't have them unless its new parent folder also has them.
I do have the authority as I'm the domain administrator, so that is not an issue.
Chris's permissions are set specifically on that folder and are not inherited from any parents.
Just done some more checks, and it looks like the fodders and files within the 'Chrisk_Projects' folder have the permissions set correctly, it's just the top level folder that has the issue. Now I did cancel the copy part way through when it looks not to be working so I'm wondering if the permissions are set at the end of the copy process. If that is the case then that could be the cause of the issue.
That changes things quite a bit. If you abort something before it's finished then it's not surprising to see unfinished results. Including that information when asking if there was a bug would've saved some time/thinking.
I don't know for sure but it would make sense if the permissions were set on each folder when its contents were finished copying, rather than before they were started. The permissions may deny your own account write-access so it makes sense to set them at the end, not the start, in a depth-first fashion.
As suggested, try with a SMALL test directory first to see if things work before trying with the large, real data. That will make checking things much quicker, easier and more accurate.
(Are you really using Windows 8 Consumer Preview as the client to do this work on two real network file-servers? That's brave...)
I had thought that the copy had got past this folder when I first raised the question otherwise I would have stated that. You know me better than that Leo
That folder has 3.9Gb of files in it with complex permissions as it's travelled through so will make a good test when it completes.
And yep, been running the Windows 8 Consumer preview since it came out with no issues at all.
Okay the copy of the 'Chrisk_Projects' folder has just completed but the permissions are not set correctly, they are as I originally reported.
Now that the copy has completed there are some weird permissions:
\server-bri11\d$\Common_Files\Engineering_Design\Chrisk_Projects\ARCHIVE\ - No security set for Chris
\server-bri11\d$\Common_Files\Engineering_Design\Chrisk_Projects\ARCHIVE\Laser CRT\LaserCRT 005.jpg - Permissions correct
\server-bri11\d$\Common_Files\Engineering_Design\Chrisk_Projects\ARCHIVE\Laser CRT\Laser CRT_files\ - No security set for Chris
\server-bri11\d$\Common_Files\Engineering_Design\Chrisk_Projects\ARCHIVE\Laser CRT\Laser CRT_files\themedata.thmx - Permissions correct
In fact all the checks I've done show the security is correct on files but not for folders.
It looks like permissions not set on folders which are below a folder which is being "merged."
So, with the Chrisk_Projects folder selected in the source, if that folder already exists in the destination, then the permissions will not be set on any folders below it (even ones which are created during the copy). Permissions will only be set on the files.
If the Chrisk_Projects folder does not already exist in the destination, then all the permissions on both files and folders should be copied over.
Does that explain what you're seeing?
I'm not sure if what we're doing is completely right, but that seems to be the current behaviour. (I think it makes sense not to change permissions on dirs which already exist, but if we create a dir, and are set to copy permissions, then it seems right to set the permissions on that dir. Or, "more predictable" is probably a better phrase than "right," since I can see situations where both ways might make sense, and there isn't really a canonical way to deal with permissions when partially-merging two folders.)
Okay I had resumed the copy with the folder left in place. I've now deleted it and restarted the copy so now that the destination folder does not exist we'll see what transpires.
