In the past few months I've noticed a number of situations where a BLPackage deploy job would throw errors due to missing files in the staging directory. Getting to the root cause of these errors requires an understanding of how files are managed in the depot and in the target's staging directory.
Here's an example of how this error has manifested itself. Today I was troubleshooting a deploy job which failed because it could not open a file in the staging directory. If we go back a step, the file should exist in the depot. Looking at the depot, it wasn't there either. By examining the bldeploy.xml in the staging directory, we can ascertain the name of the missing file. The missing file is named c4de4a6bd867480a20ea98980a318c7c. According to the bldeploy.xml, it corresponds to a destination file named myapp.dll.
Since we know the name of the destination file, and the name of the file in the depot, what's to stop us from manually putting it in the depot, to make the error go away? That's just what I did. At the file system level I copied myapp.dll to the depot, renamed it, then re-ran the deploy job.
So the problem is solved.
But this leaves dozens of questions.
As I understand it, the names of the files in the depot are hashed because there is no directory structure. If it wasn't for this, it would be impossible to have a BLPackage with two identical files in it. At the same time, there seems to be a mechanism in operation which minimizes duplicate entries. Is this true? I haven't seen any documentation which describes how files in depot are managed.