Failed to move classes/pages

[Kamil Pilarski]

Sometimes, after retrieving metadata, an error appears and says it failes to move metadata to temp folder. It looks like this:

After that, the files of the mentioned metadata end up in unpackaged/src folder, rather than in src/. I'm not quite sure how to reproduce the error. It just happens from time to time during retrieval and usually it works ok with the next try.

[Scott Wells]

Yeah, this seems to happen when something has a lock on the file when I try to move it. I think the best I could do is to retry the move operation a few times before failing in the hopes of outlasting the lock since it does seem to be short-lived/transient. I'll take a look at that to see if it resolved/minimizes the frequency of the error.

[Scott Wells]

Issue #535 was marked as a duplicate of this issue.

[Scott Wells]

Over lunch I submitted what I hope is a fix for this. I'll include the change in the next build and will need feedback from you guys as to whether it resolves the issue or not (I'm not able to reproduce it).

[Scott Wells]

Prospective fix delivered in 1.7.8.1. As I was unable to reproduce it, please reopen if you still see the issue.

[N Morrish]

Still experiencing this in 1.7.8.5.

Note: When the sync fails, it leaves a 0k file in the folder it failed for.

In my case: I am receiving "failed to copy classes". After the sync there is a new 0k file called "classes/classes".

Perhaps that is a clue.

[Scott Wells]

Thanks for letting me know. I'll take another look for one of the near-term builds (ideally the next one).

[Scott Wells]

Okay, I have another fix in place in 1.7.8.6. For this one I forced the issue to reproduce by locking a file explicitly as it was being renamed/moved. The fix in this case is to try to move/rename the file first for efficiency, then failing that, copy the file to the destination and try to delete it afterward. If the delete fails, the operation will not fail overall, but the resulting directory structure may still have the unpackaged directory and all contents which could not be moved when it's shown in the directory diff. For now just ignore that.

Right now I'm working on a tight Salesforce DX integration where I'm having to change the way I handle the retrieved package directory structure, so I'm addressing this in a different way that won't have the same potential issues as part of that work. In the interim, hopefully this eliminates the issue where a potentially expensive retrieve operation has to be repeated for success.