Job simulation enables you to do a “mock run” of a job. At the end of the simulation run, you can look at reports that tell you what files would have transferred, how many bytes of data would have transferred, and what files, if any, would be deleted. Simulation can be used in situations such as:
- Identifying the size of content on the source, as number of files and total bytes.
- Assessing how many files and bytes will transfer during synchronization runs. You can also identify the files that will transfer during the sync so you can evaluate whether you want to do the sync run at all.
- Identifying and troubleshooting transfer errors on specific files, such as Access denied, more quickly than during an actual transfer run. Simulation can also sometimes be useful for evaluating drive and network connectivity problems.
- Determining estimated time to complete the run, and any bottlenecks that may limit the speed of your transfer. See below for additional information on completion time estimates.
- For jobs where Mirror Deletions is turned on, Simulation will list the files that will be deleted from the target when the job is actually run.
- Simulations are highly recommended for Account Mapping jobs and any other jobs where Target Paths may be affected by multiple factors. See below for a description of some of the factors that can change target path structure.
- Simulation jobs do not identify all potential errors in a migration. Notably, many platform-specific errors are not reported. See below for further information.
- To run a simulation job, simply click on the job name and select the Run Simulation button:
A Simulation job is an actual job and, while it doesn’t transfer any data, it uses POP resources. The usual rules apply where you should only run one job at a time for any given POP(s).
- When the Simulation job completes, click on the Simulation button, which takes you to the Simulate tab of the Job modal. You can view historical statistics of your sim run:
Or click Current Simulation Results to view a report of the files tagged for transfer:
- This is also useful for account mapping, where you can view which accounts your files will go to. To filter results, click the All Results menu and select a subset of your files and directories. You can also click the magnifying glass to filter your results further. Additional information on filters is available at Job History Filters.
Click the Export button in the lower left corner to download an .xlsx file of your sim run. The Translated File Name column on the far right of the spreadsheet will show you the precise path for your data on the target.
What Factors Change Target Paths?
- See Defining Paths for Your Data for an introduction on how target paths are determined. Other factors influencing target path structure are listed below.
- Source-Target character conversions: a character in a file or folder name may be valid on the source, but not on the target. CFP will automatically convert these invalid characters, according to the source and targets in use. For example, some unicode characters are valid on Windows, but are not supported on other platforms. In this case, they will be converted to their unicode equivalents (e.g., é will be converted to U+00E9). In the event that there is a character conversion, CFP will run any syncs using the same character conversions.
- Namespacing: if data from two source accounts is transferred to a common target path, CFP will set up separate folders in the target path for each account. Example: if you transfer a root folder called Documents from account UserA, and a root folder called Documents from account UserB, and the destination for both of these folders is /Project, you will have the following target paths:
- /Project/UserA/Documents and
This ensures that the two ‘Documents’ folders from the two source owners remain separated, and their contents aren’t mixed together in one folder. Namespacing applies to any two or more accounts that are sent to a common destination within the same job, i.e., CFP will namespace even if there are not foldernames in common between the two accounts.
By default, namespaced folders created on the target are labeled with the user name from the source. If the user name is not available, email will be used.
- Account mapping path manipulations: many redirects and path manipulations can be executed via the Account mapping spreadsheet. The simulation ensures that these manipulations will yield expected results. See Account and Permissions Spreadsheet Editing for details.
What Errors are Not Reported on Simulations?
Some errors are not reported on simulations:
- Exceeding Target Limitations: targets have many limits – max overall number of files, sharees, items per folder, file size, and so on. In many cases, CFP does not know at the time of simulation whether a target limit will be exceeded. For example, if the target drive has an absolute maximum number of items, but the job is going to an empty folder within that drive, CFP won’t scan the rest of the drive – and will have no knowledge of how many items are already there. For that reason, most limits for number of ‘items’ per filespace are not elucidated in simulation. Max file size or unsupported file type – which are more of an absolute evaluation – generally are flagged.
- Errors Contingent on Target Server Response: some errors, including some permission errors, are dependent on a number of factors that don’t surface unless CFP attempts to make the server requests needed to transfer the item, and then wait for the request to come back for it. This can dramatically increase the time needed to run the actual simulation. To meet customers’ needs for faster verification of items such as target path structure, simulations do not check for many of these errors.
About Completion Time Estimates
One of the things that happens in a simulation is that CFP sends a small quantity of data between the source to target, and then discards it. That’s used to measure the overall performance of job elements such as bandwidth and download/upload rates, but it is a snapshot and cannot fully account for conditions such as throttling, winapp resource (CPU/memory) consumption, target service slowdowns/outages, and other factors. For these reasons, completion time estimates should be considered as best case, and transfer jobs frequently take longer than estimated.