I'm not a unix guru, but I'd say that would be your best bet. Alternatively, you may want to do it in two steps... copying files to an external volume which is set to ignore privileges then back again to another location.
The UNIX command 'ditto' has crossed my mind - I believe it's supposed to copy files like 'cp' does, but preserves the file permissions for every item it copies instead of acting as the currently logged in user.
I'm curious about the transfer of secure managed containers in this way, there is a checksum on each encrypted file which will also have to survive the transfer. That should be OK, but if anyone has experiences to share, they would be much appreciated.
-- Drew Tenenholz
You may want to do a "save a copy as - self contained" after closing the file on FMS (and opening it in FMP). That "sucks" in all the remote container data so that you have just the one FM file. Easier to redeploy.
Once it is hosted on the new server you can reset the containers back to external storage and FM will take care of putting the files where they belong.
Just to be absolutely clear, I think the steps you are suggesting are:
1) On the old machine, Use FMS Admin Console to 'Close All Files'
2) Use FMPro to open the files and then File > Save A Copy - Self Contained' for each file with remote containers.
3) Transfer the files to a disk accessible to the new machine (could be old machine in Target Disk Mode, could be an externally connected FireWire or Thunderbolt drive).
4) On the new machine, use the FMS Admin Console to 'Upload' the files into FMServer
If so, there are a couple of difficulties with this process I'd like to avoid:
A) This is a 35+ FILE solution. Containers are used in a small number of files, and although I have a set of 'upgrade' scripts that save copies of the files, none of these scripts have the 'save as self-contained' option in them already. I suppose these could be added before even beginning the process and adding them to the existing 'upgrade' process.
B) There are 5-10 GB of data here, other copies of this system are even larger. The process above means writing out the files TWICE (once with FMPro, once with the 'upload' in FMServer). I'd prefer to save the time of writing out the files twice if at all possible.
Thanks for clarifying,
On 2) --> pretty much, although depending on the path currently used for the container you may have to COPY (not move) the folder of the container data relative to where the unhosted FM file expects it. The path can be slightly different than what the hosted file sees.
As to 4) and B) -> you can forgo the "upload through admin console" since you will have just the FM file, no external container data. So you can just drop the FM file in place, set the privileges correctly and be done.
An emerging best practice is to keep a container FM file when using remote containers instead of using container fields through different tables and files. That makes this process a lot less risky.