Failed to move classes/pages
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.
Comments (10)
-
repo owner -
repo owner Issue
#535was marked as a duplicate of this issue. -
repo owner 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).
-
repo owner -
assigned issue to
- changed version to 1.7.8.1
-
assigned issue to
-
repo owner - changed status to resolved
Prospective fix delivered in 1.7.8.1. As I was unable to reproduce it, please reopen if you still see the issue.
-
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.
-
repo owner - changed status to open
Thanks for letting me know. I'll take another look for one of the near-term builds (ideally the next one).
-
repo owner - changed version to 1.7.8.6
-
repo owner - changed status to resolved
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.
-
repo owner - changed component to Metadata Deployment/Retrieval/Removal
- Log in to comment
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.