Case Insensitive Filesystem Breaks Metadata Subscription
Issue #1813
resolved
In an SFDX project, with the subscription mode defaulted to the greyed out ‘All’ option, I had weird behaviour when a filename had a capital where the org/class-name had a lowercase. (probably old copy of the file)
- Deploy/retrieve refused to show it as subscribed (when module config said it was)
- Compare With Server retrieved metadata, but then did nothing but display a ‘Retrieve successful’ message
Comments (3)
-
repo owner -
repo owner By the way, this issue exists not just for a case-insensitive file system. Even on a case-sensitive filesystem you could reproduce the issue as follows:
- Create a class named
Issue1813
contained in local filesIssue1813.cls
andIssue1813.cls-meta.xml
. - Deploy that class successfully to Salesforce.
- Rename the local files to
issue1813.cls
andissue1813.cls-meta.xml
and update the class name itself toissue1813
. - Try to deploy the class via the metadata API or retrieve it and it will fail without the fixes mentioned above. Note that deployment via the tooling API will work because it deploys by ID. That deployment will result in the
ApexClass
object's name being updated toissue1813
.
With these fixes all of this will work, and deployment via the metadata API will now behave like deployment via the tooling API where the case of the server version's name will be updated to reflect the case of the local version's name.
Ahhhh....fun with case-insensitivity...the gift that keeps on giving.
- Create a class named
-
repo owner - changed status to resolved
Delivered in 2.1.6.1.
- Log in to comment
I just committed a few fixes for this issue:
package.xml
which ensures that the server name's case is updated to reflect the local name.package.xml
since evidently matching against the retrieval manifest occurs in a case-sensitive manner.This will all be included in the next build.