sublime_text

sublime_text copied to clipboard

Description of the bug

• The portable version of ST for Windows stores its data in a directory called Data in the same directory where sublime_text.exe is.
• If you want to use a different directory, the only option I'm aware of is to use a symlink.
• Symlinks may be relative (that is, the path stored in the symlink is something like ..\data).
  • In this case, the path is resolved relative to the location of the symlink, e.g. a symlink at D:\dir\symlink with path ..\data will be resolved to D:\data.
• During startup, ST seems to check if the Data directory is a symlink, and in case it is, use the target directory directly.
• However, if the symlink is a relative path, it is resolved relative to the working directory ST was launched from, not relative to the directory where Data is (as it should be).
• This results in ST creating random new data directories around the filesystem whenever you open a file.

Steps to reproduce

(commands are executed in cmd.exe for simplicity)

1. Download the portable version of ST and extract it to a directory, I'll use D:\st\app.
2. Create a custom data directory: mkdir "D:\st\data"
3. Remove the default data directory: del "D:\st\app\Data"
4. Symlink the data directory elsewhere: mklink /D "D:\_\Sublime Text\app\Data" ..\data
5. Create a text file at D:\st\file.txt: echo. >D:\st\file.txt
6. Open the file using ST:

cd /d D:\_
"D:\st\app\sublime_text.exe" .\file.txt

• NOTE: it is important to do it from cmd, because by opening it from File Explorer, the working directory is automatically set to the app directory, which hides the issue.

8. Observe that a data directory is created at D:\data.

Expected behavior

ST either does not resolve the symlink at all and leaves it up to the system, or resolves it to the correct path (relative to the symlink location, not current working directory).

Actual behavior

The data directory is created in the wrong place.

Sublime Text build number

4126

Operating system & version

Windows 10 21H2

(Linux) Desktop environment and/or window manager

No response

Additional information

No response

OpenGL context information

No response

This is how relative symlinks work; they're always relative to the working directory, no?

This is how relative symlinks work; they're always relative to the working directory, no?

As you can test on both Windows any (I believe) any POSIX-compliant system, the relative path is resolved relative to the location of the symlink, not the working directory (which wouldn't be very useful).

We seem to be handling symlinks wrong on Windows; a fix is in the pipeline.

Fixed in build 4135.