[GH-ISSUE #1735] [Bug]: Critical data loss during Desktop migration: symlink target directories were emptied #532

New issue

Open

opened 2026-10-31 22:14:09 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 22:14:09 +00:00

Owner

Originally created by @AI-Hikaru on GitHub (Jun 8, 2026).
Original GitHub issue: https://github.com/Comfy-Org/desktop/issues/1735

App Version

0.24.1

Expected Behavior

The Desktop migration should preserve all existing user data.

In particular, if legacy ComfyUI folders are symbolic links, junctions, or other reparse points, the migration should not recursively delete, clean, empty, or otherwise modify the real target directories.

Expected behavior would be:

Existing models, output, and custom_nodes directories are preserved.
Symbolic links / reparse points are detected before migration.
The migration either keeps the existing linked directories as-is, or asks for explicit confirmation before touching them.
The app clearly shows which physical directories will be modified.
No existing user files are deleted during migration.

Actual Behavior

After launching ComfyUI Desktop 0.24.1, I was shown the new screen asking me to choose between server/local. I selected Local, and a migration from my previous/legacy setup started.

After the migration completed, the real target directories used by my previous symbolic-link setup had been emptied.

This was not only a missing path/reference issue. The actual target folders on disk were emptied.

My previous linked target directories were:

F:\ComfyUI\custom_nodes
F:\ComfyUI\output
R:\ComfyUI\models

After migration:

F:\ComfyUI\custom_nodes
F:\ComfyUI\output

were emptied.

For:

R:\ComfyUI\models

the subfolders remained, but the files inside the subfolders were removed/emptied.

My storage layout was:

F: ReFS / Windows Storage Spaces mirror
R: ReFS / Windows Storage Spaces simple volume

I was able to recover the output folder using recovery software, but this was a critical data loss event.

Steps to Reproduce

I cannot safely reproduce this again because it caused data loss, but the setup and sequence were:

Use ComfyUI Desktop / legacy ComfyUI setup on Windows.
Redirect some ComfyUI directories using symbolic links / reparse points to other drives.
In my case, the linked target directories were:

F:\ComfyUI\custom_nodes
F:\ComfyUI\output
R:\ComfyUI\models

The target drives were ReFS volumes on Windows Storage Spaces:
- F: = mirror
- R: = simple volume
Launch ComfyUI Desktop 0.24.1.
When prompted to choose between server/local, select Local.
Let the legacy migration complete.
Check the real target directories used by the symbolic links.

Observed result: the real linked target directories were emptied, including output, custom_nodes, and model files inside the model subfolders.

This issue does not depend on a specific workflow JSON or custom node. It occurred during Desktop startup/migration before normal workflow usage.

Debug Logs

Browser Logs

No response

Settings JSON

No response

Other

No response

Originally created by @AI-Hikaru on GitHub (Jun 8, 2026). Original GitHub issue: https://github.com/Comfy-Org/desktop/issues/1735 ### App Version ```text 0.24.1 ``` ### Expected Behavior The Desktop migration should preserve all existing user data. In particular, if legacy ComfyUI folders are symbolic links, junctions, or other reparse points, the migration should not recursively delete, clean, empty, or otherwise modify the real target directories. Expected behavior would be: * Existing `models`, `output`, and `custom_nodes` directories are preserved. * Symbolic links / reparse points are detected before migration. * The migration either keeps the existing linked directories as-is, or asks for explicit confirmation before touching them. * The app clearly shows which physical directories will be modified. * No existing user files are deleted during migration. ### Actual Behavior After launching ComfyUI Desktop 0.24.1, I was shown the new screen asking me to choose between server/local. I selected **Local**, and a migration from my previous/legacy setup started. After the migration completed, the real target directories used by my previous symbolic-link setup had been emptied. This was not only a missing path/reference issue. The actual target folders on disk were emptied. My previous linked target directories were: ```text F:\ComfyUI\custom_nodes F:\ComfyUI\output R:\ComfyUI\models ``` After migration: ```text F:\ComfyUI\custom_nodes F:\ComfyUI\output ``` were emptied. For: ```text R:\ComfyUI\models ``` the subfolders remained, but the files inside the subfolders were removed/emptied. My storage layout was: ```text F: ReFS / Windows Storage Spaces mirror R: ReFS / Windows Storage Spaces simple volume ``` I was able to recover the `output` folder using recovery software, but this was a critical data loss event. ### Steps to Reproduce I cannot safely reproduce this again because it caused data loss, but the setup and sequence were: 1. Use ComfyUI Desktop / legacy ComfyUI setup on Windows. 2. Redirect some ComfyUI directories using symbolic links / reparse points to other drives. 3. In my case, the linked target directories were: ```text F:\ComfyUI\custom_nodes F:\ComfyUI\output R:\ComfyUI\models ``` 4. The target drives were ReFS volumes on Windows Storage Spaces: * `F:` = mirror * `R:` = simple volume 5. Launch ComfyUI Desktop 0.24.1. 6. When prompted to choose between server/local, select **Local**. 7. Let the legacy migration complete. 8. Check the real target directories used by the symbolic links. Observed result: the real linked target directories were emptied, including `output`, `custom_nodes`, and model files inside the model subfolders. This issue does not depend on a specific workflow JSON or custom node. It occurred during Desktop startup/migration before normal workflow usage. ### Debug Logs ```powershell ``` ### Browser Logs _No response_ ### Settings JSON _No response_ ### Other _No response_

bsakaguchi added the

Potential Bug

label

2026-10-31 22:14:09 +00:00

bsakaguchi referenced this issue

2026-10-31 22:18:01 +00:00

[PR #532] [MERGED] [chore] Update frontend to 1.6.1 #916