"Unsafe character sequences" error when using temporary directories

[jonathanmorris180]

Summary

When a file is pulled into a temporary directory using sf project retrieve start, the CLI returns the following error:

Metadata API request failed: The filepath \"../../../../../var/folders/jd/60r8p0wj7zg_g4bxf1ff9_hc0000gn/T/nvim.jonathanmorris/DmC8ty/1/main/default/classes/ChallengeSetting.cls\" contains unsafe character sequences

This is causing issues for a Neovim plugin I have written as I use temp directories to diff files in the org. After I retrieve a file into a temp directory for diffing with the file in the current project, I can no longer push components to the org because the error is thrown. The only workaround I have found to fix the issue is to rm -rf .sf/orgs/* in the project after I have run a diff.

Steps To Reproduce

Run the following script (replace <username-or-alias> appropriately):

# Set up test
org_alias=<username-or-alias> # Replace
sf project generate --name example --template empty
cd example
classes_dir="force-app/main/default/classes"
mkdir -p "$classes_dir"
sf apex generate class --name TestClass --output-dir "$classes_dir"
sf project deploy start -d "$classes_dir" -o "$org_alias"

# Reproduce bug
temp=$(mktemp -d)
mkdir -p "$temp/$classes_dir"
sf project retrieve start -m "ApexClass:TestClass" -r "$temp" -o "$org_alias"

# Clean up
rm -rf "$temp"
cd .. 
rm -rf example

Expected result

The component should retrieve from the org into the temp directory without any issues.

Actual result

Error is thrown.

System Information

System Version: macOS 14.6.1 (23G93)
Shell info:

zsh 5.9 (x86_64-apple-darwin23.0)

sf version --verbose --json output:

{
  "architecture": "darwin-x64",
  "cliVersion": "@salesforce/cli/2.57.7",
  "nodeVersion": "node-v20.16.0",
  "osVersion": "Darwin 23.6.0",
  "rootPath": "/Users/jonathanmorris/.local/share/sf/client/2.57.7-291554e",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.2 (core)",
    "@oclif/plugin-commands 4.0.13 (core)",
    "@oclif/plugin-help 6.2.10 (core)",
    "@oclif/plugin-not-found 3.2.18 (core)",
    "@oclif/plugin-plugins 5.4.6 (core)",
    "@oclif/plugin-search 1.2.7 (core)",
    "@oclif/plugin-update 4.5.5 (core)",
    "@oclif/plugin-version 2.2.11 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.13 (core)",
    "@oclif/plugin-which 3.2.12 (core)",
    "@salesforce/cli 2.57.7 (core)",
    "apex 3.4.5 (core)",
    "api 1.2.1 (core)",
    "auth 3.6.51 (core)",
    "data 3.6.3 (core)",
    "deploy-retrieve 3.12.0 (core)",
    "info 3.4.2 (core)",
    "limits 3.3.27 (core)",
    "marketplace 1.2.24 (core)",
    "org 4.5.4 (core)",
    "packaging 1.27.0 (user) published 312 days ago (Tue Oct 31 2023) (latest is 2.8.4)",
    "schema 3.3.26 (core)",
    "settings 2.3.15 (core)",
    "sobject 1.4.32 (core)",
    "source 3.5.16 (core)",
    "telemetry 3.6.10 (core)",
    "templates 56.3.14 (core)",
    "trust 3.7.25 (core)",
    "user 3.5.26 (core)",
    "@salesforce/sfdx-diff 0.0.6 (user) published 1661 days ago (Thu Feb 20 2020)"
  ]
}

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[iowillhoit]

Hello @jonathanmorris180, it looks like this error is happening because source tracking is trying to track a file outside of it's root directory and it is not allowed.

If you run the command with the --dev-debug flag, you will see an error coming from the source tracking "shadow repo" which uses the isomorphic-git library. Here is an example in iso-git where they throw an error when the path includes going up a directory. This was patched in this iso-git PR

One way to avoid this would be to create an org without source tracking:
sf org create scratch --no-track-source

Or you could do the retrieve in metadata format instead of source format, this bypasses source tracking (source-code)

Retrieve in metadata format (and unzip)
sf project retrieve start -m "ApexClass:TestClass" --target-metadata-dir /your/tmp/dir --unzip

Then if you need to convert it to source format you could with:
sf project convert mdapi --root-dir /your/tmp/dir/unpackaged --output-dir /your/tmp/dir/converted

[jonathanmorris180]

Hi @iowillhoit, thanks for looking into this. Interesting to learn about the shadow repo! Retrieving in metadata format fixed the issue.

[Kevmo92]

@iowillhoit do you know if running the sf org disable tracking command would work around this issue as well?

[frrio]

@iowillhoit do you know if running the sf org disable tracking command would work around this issue as well?

It did for me.