When running OM with the DCTM source and the hasFilestoreAccess flag set to True, the source verifies that the content file exists prior to retrieving the file. This check assumes that OM is either a) running on the content server iteself or b) has a drive mapped to the exact content location, right down to the drive letter 'D:' or 'Z:', etc... If you want to map a different drive to the filestore, you get an error that the content file doesn't exist.
The following is Chuck's detailed explanation:
We are running OM with direct filestore access from a machine other than the filestore (because of hard drive space issues). There is a hiccup in the logic when this happens.
In AbstractMigrationSourceDocumentum, loadNodeContent method (at line 593), we call:
File fileStoreFile = DocumentumUtil.getFileStoreFile( storeBean, docbaseId, dataTicket, fileExtension );
Looking inside DocumentumUtil.getFileStoreFile(...), we call another helper method to give us the filePath of the content object; which will give us the file path of the content object on the content server. In our case something like d:\dctm\data\ami\foo.
in Line 258 of DocumentumUtil.getFileStoreFile(...) we perform a check to make sure that the current source file exists: if (contentFile.exists()). Uh oh. The file does exist on the file system of the content server (which we have mapped to something other than the D: drive), but as far as the machine running open migrate is concerned, the file does not exist at the d:\dctm\data\ami\foo path.
In short, when running with direct file access, we either need to run on the content server, or map a network drive to a drive letter that is the same as the content server's drive. Luckily the machine we are running on has a free D:\ drive; so, we mapped AMI's content server's D drive to D:\ on the machine running OM.