1.2tb of models lost in ComfyUI Migration/Import

[pr0dukt]

Package

ComfyUI, Kohya_ss

When did the issue occur?

Installing the Package

What GPU / hardware type are you using?

Nvidia RTX 5080 16GB

What happened?

I literally can’t think of a single reason why there isn’t even so much as a warning, before SM just hard deletes a folder with over a TB of data in it… it’s honestly inexcusable. I was just trying to move my comfyui instance from my own locally ran venv to SM and have my models folder shared between it, and my Kohya_ss package, and immediately have my models, nodes and workflows instantly deleted. The only folder it didn’t nuke is my output folder, which means I can get most of my workflows back, as well as an archive of custom node suites I need to redownload, but that TB of models, including several of my own trained LoRAs are just gone now.

Please. Please. For the love of god, put some safety nets in place for this kind of thing. That was WAY too easy to do without having any kind of indication that it’s going to happen, the opposite in fact, the reading I did go over about importing packages into SM, all make it seem completely safe, and that it would merely move yyour models folder to a more centralized location in SM’s file structure for all packages to pull from.. nowhere does it give any indication of it just nuking your comfyui folder entirely and forcing you to start with absolutely nothing, without any recourse or method of reversing the damage.

Anyways I don’t how im going to proceed, I’m surprised I’m not in tears over this, it probably hasn’t entirely sunk in yet. But I do need to start rebuilding my models library and salvage what workflows I can. Just wanted to make this known and implore the folks managing SM to add some reasonable safety nets in place. Anyone running Comfy on a personally made venv and is looking for alternative ways to launch it and decide they like the SM ecosystem could just as easily make the mistake of thinking they can just import thier existing Comfyui folder in its entirely into SM smoothly, be left with a crater on thier hard drive and left with no option but to rebuild from scratch. It’s pretty demoralizing. 😕

Console output

I’ll have to update this to include console output. I’m at work now. Happened this morning. A lot was just useless verbose, and it happened so fast it would have been impossible for me to stop it, even if I was trying to follow console in realtime..

Version

Latest

What Operating System are you using?

Windows

[mohnjiles]

Hi @pr0dukt — really sorry for the scare, losing access to a library you've built up (including your own trained LoRAs) is awful. But before you start rebuilding: please don't assume the files are gone. We went through the import and shared-folder code paths today, and there is no step in them that deletes model files. What they do is move files into Stability Matrix's central shared Models folder so all packages can use them. There's a very good chance your 1.2 TB is still on disk. Here's where to look:

1. Check the shared Models folder. It's inside the Data directory you picked when you first set up Stability Matrix (e.g. C:\StabilityMatrix\Data\Models, or next to the portable exe). When shared folders are set up in symlink mode, everything inside the package's models subfolders gets moved there and sorted by type:

• models\checkpoints → Models\StableDiffusion
• models\loras → Models\Lora
• models\vae → Models\VAE
• models\controlnet → Models\ControlNet
• models\diffusion_models → Models\DiffusionModels
• models\clip → Models\TextEncoders … and so on.

The Checkpoints page inside the app browses this same folder. The original ComfyUI subfolders are then replaced with links pointing at those locations — so in Explorer your old folder can look empty or strange even though the files are fine.

2. If your models folder was itself a symlink/junction (e.g. pointing at another drive), Stability Matrix replaces the link with a fresh empty folder — the link itself is removed, but the files at the link's original target are untouched. Check the location the link used to point to.

3. Two quick sanity checks that settle it either way:

• Search your drives for *.safetensors (Windows search, dir /s, or the Everything app). A move shows up immediately; 1.2 TB doesn't vanish without a trace.
• Check your drive's free space. Deleting 1.2 TB frees 1.2 TB; moving files on the same drive frees nothing. If your free space didn't jump by a terabyte, the models are still there.

4. Workflows live under Data\Workflows when shared (ComfyUI's user\default\workflows\Stability Matrix is a link to it), and the sharing logic doesn't touch custom_nodes at all — so if nodes are missing too, something else happened than what the import normally does, and we'd really like to see what.

Could you post:

• your log files — in the app: Settings → Open Logs, or grab the folder at %APPDATA%\StabilityMatrix\Logs — plus the console output you mentioned;
• the exact steps you took (did you move your ComfyUI folder into Data\Packages and click Import? enable "shared model folders" on the package card? install/uninstall anything along the way?);
• whether your models folder (or subfolders in it) were junctions/symlinks.

On your actual point: you're right that this should never be a surprise. Relocating a user's files with no warning, confirmation, or summary of what moved where is a legitimate UX failure even when nothing is lost, and we'll keep this issue open to track adding a proper warning/confirmation step to the import and shared-folder flows.

One ask: please keep everything related to this in this thread rather than commenting on other issues/discussions — it keeps the details in one place and gets you help faster.

---

Generated by Claude Code

[pr0dukt]

I’m still at work but unless they moved them off drive they are gone. As I did check my overall C drives storage and it dropped by that over a TB. Which is why it felt like my drive just nuked in like under 10 seconds.
I was hoping it at least spared my comfy snapshots so I can at least get a shopping list for the rebuild, but I’m not terribly optimistic since all my workflows in /user/default/workflows and my custom nodes folder also got wiped. It treated the whole process more like a factory reset than actually “importing” anything.

It defiantly blindsided me. But yeah I’ll keep discussion of it in this thread.. if I can even somehow recover one of my recent snapshots even I’ll be feel a lot better. I can DL everything (mostly) again, I just need that list, I had alot of data packed in and a bunch of custom node suites from off the beaten path I doubt I’ll get back but if I can get the bulk even I’d feel better. 😮‍💨

[pr0dukt]

Follow-up with logs + the actual code path. Just so this gets fixed and doesn't happen again to anyone else. The earlier comment that "there is no step that deletes model files" is not correct. The files were not moved into Data\Models. Free space on C: jumped by ~1.2 TB in seconds, which is an unlink, not a same-volume move. Data\Models was empty afterward (model index 0 entries). custom_nodes and user\default\workflows were gone too. Only output survived, and that is because it was already a junction.

What I did

Existing standalone ComfyUI lived at C:\ComfyUI (~1.37 TB of weights, 156 custom-node packs, ~180 workflows). I moved that tree into SM’s default package path so it could be imported and share models with Kohya:

C:\Stability Matrix\Data\Packages\ComfyUI

That is the same hardcoded path one-click install uses.

What the logs show (2026-08-31, local time)

1. Shared-folder teardown treated a real models folder as a junction

%APPDATA%\StabilityMatrix\Logs\app.2026-08-31 07_45_34.log:

2026-08-31 07:39:38.8084|INFO|StabilityMatrix.Core.Helper.SharedFolders|Deleting junction target C:\Stability Matrix\Data\Packages\ComfyUI\models\checkpoints
2026-08-31 07:39:54.1227|ERROR|StabilityMatrix.Avalonia.Program|Unobserved Task Exception|System.IO.IOException: The directory is not empty. : '...\models\checkpoints'.
   at System.IO.FileSystem.RemoveDirectory(...)
   at StabilityMatrix.Core.Helper.SharedFolders.RemoveLinksForPackage[T](...)
   at StabilityMatrix.Core.Models.Packages.BaseGitPackage.RemoveModelFolderLinks(...)
   at StabilityMatrix.Core.Models.Packages.ComfyUI.RemoveModelFolderLinks(...)

That folder was a real directory full of checkpoints, not a junction. The log line is the giveaway: the function always prints “Deleting junction target” and then Directory.Delete with no reparse-point check.

2. Package card started deleting the tree

2026-08-31 07:45:11.6694|INFO|StabilityMatrix.Avalonia.ViewModels.PackageManager.PackageCardViewModel|Removing junction point C:\Stability Matrix\Data\Packages\ComfyUI\output

3. One-click install then wiped Packages\ComfyUI and cloned a fresh v0.34.0 over it

2026-08-31 07:46:02.0127|DEBUG|...PackageImportViewModel|Release mode: False
2026-08-31 07:46:22.3015|INFO|...NewOneClickInstallViewModel|Removing junction point C:\Stability Matrix\Data\Packages\ComfyUI\web\extensions\ComfyLiterals

Immediately after that, git/uv installed a clean ComfyUI v0.34.0 into the same path. Package files in Data\Packages\ComfyUI are timestamped 07:46. Model index stayed at 0. Data\Models\* empty except a LoRA downloaded later that evening.

That is why it felt like a factory reset in under 10 seconds: NTFS unlinked the tree. A same-volume move into Data\Models would not have freed 1.2 TB.

Output “survived” only because DeleteVerbose correctly removes a junction without following it, and output had already been junctioned to Data\Images\Text2Img at 00:41. models\, custom_nodes\, and user\ were real directories, so they were recursively deleted.

Settings at the time:

• MoveFilesOnImport: true
• PreferredSharedFolderMethod: Configuration (ComfyUI default)
• RemoveFolderLinksOnShutdown: false

The code

A. One-click install deletes whatever is already at Packages\{Name} with no size check and no confirmation of user data

NewOneClickInstallViewModel.cs:

var installLocation = Path.Combine(settingsManager.LibraryDir, "Packages", selectedPackage.Name);

if (Directory.Exists(installLocation))
{
    var installPath = new DirectoryPath(installLocation);
    await installPath.DeleteVerboseAsync(logger);  // recursive delete of the whole tree
}

DeleteVerbose does skip following junctions (that is why output and web\extensions\ComfyLiterals only lost the link). It then enumerates every real subdirectory and deletes every file. If a user has just moved a 1.2 TB ComfyUI install into Packages\ComfyUI because that is where Import/docs tell them to put it, this is a silent wipe.

Same helper is used by package uninstall (PackageCardViewModel.Uninstall → packagePath.DeleteVerboseAsync).

B. RemoveLinksForPackage does not check that the path is a junction

SharedFolders.cs:

Logger.Info($"Deleting junction target {destination}");
Directory.Delete(destination, false);

No IsSymbolicLink / FileAttributes.ReparsePoint test. On a real non-empty models\checkpoints this throws IOException: The directory is not empty (exactly the 07:39 unobserved exception). The log text also implies the target of a junction is being deleted, which is the classic Windows footgun.

C. Toggling shared-folder method calls that remover

PackageCardViewModel OnIsSharedModelSymlinkChanged / OnIsSharedModelConfigChanged: when a method is toggled off, it calls RemoveModelFolderLinks → RemoveLinksForPackage.

D. Import then reconfigures shared folders

PackageImportViewModel.AddPackageWithCurrentInputs force-recreates the venv and calls UpdateModelFolders. Combined with MoveFilesOnImport: true and symlink mode, that is a move. Combined with one-click install on the same path, it is a delete.

Why the “check Data\Models / free space didn’t jump” advice does not apply here

• Data\Models was empty. Nothing was moved there.
• Free space did jump by ~1.2 TB. That is the opposite of a same-volume move.
• custom_nodes is not a shared-folder target, and it was deleted anyway — consistent with DeleteVerbose of the whole package dir, not with shared-folder relocation.
• Searching *.safetensors after an unlink finds nothing. The clusters are free space until overwritten.

For anyone else who hits this: stop writing large files to that volume immediately and check vssadmin list shadows / Previous Versions. A shadow copy from before the wipe can still reference the unlinked clusters.

Fixes that would have prevented this

1. Never DeleteVerbose Packages\ComfyUI in one-click install if the directory contains a models\ tree, custom_nodes\, or is over a small size threshold. Prompt with byte size + file count and require an explicit “delete N GB” confirmation. Better: refuse and tell the user to pick a different folder or use Import.
2. Do not use the same path as both “drop your existing install here to import” and “one-click will recursively delete this if it exists.”
3. RemoveLinksForPackage must no-op unless the path is actually a reparse point. Never Directory.Delete a real directory. Rename the log line; “Deleting junction target” is how people lose the other side of a link.
4. Import should be configuration-only for ComfyUI (extra_model_paths.yaml). Do not move or delete the user’s models. MoveFilesOnImport should default off and warn when on.
5. Send large deletes to Recycle Bin / a staging folder, or at least log GetSize(includeSymbolicLinks: false) before wiping.
6. After import/shared-folder setup, show a summary: “moved X files (Y GB) from A to B” or “deleted nothing; wrote yaml.” Silence plus an empty Checkpoints page is how this looked like a factory reset.

This is a hobby install for me and I got lucky with a volume shadow copy. For someone whose livelihood is in that folder, the current one-click/import interaction is catastrophic. Please treat the recursive wipe of Packages\{Name} as a data-loss bug, not a UX nit.

[mohnjiles]

Hi @pr0dukt, thank you for coming back with the logs and the code path. You did our job for us here, and you're owed a correction: my earlier reply was wrong. "There is no step that deletes model files" doesn't hold for the path you hit, and your analysis of it is substantially correct. I'm sorry, both for the loss itself, and for a first response that pointed you at recovery steps that couldn't apply.

For the record, here's what your logs show happened, verified against the code:

1. 07:39: toggling shared model folders called a link-removal routine that has no reparse-point check, exactly as you found. The only reason it didn't destroy data is that the delete is non-recursive, so it threw the IOException in your log instead. The "Deleting junction target" wording is as bad as you said (though for what it's worth, it never follows a link to its target, the delete-the-other-side-of-the-link failure mode isn't there).
2. 07:45: the bulk of the deletion was the package uninstall flow. That path does show a confirmation dialog, but here's the part that's squarely on us: the dialog enumerates what will be deleted, and it only listed "Models/checkpoints" when model sharing was set to None. Your package was in Configuration mode (ComfyUI's default), which leaves models as real files inside the package folder, so the dialog affirmatively implied your models were safe while they were the largest thing about to be deleted.
3. 07:46: one-click install then recursively deleted whatever remained at Data\Packages\ComfyUI with no prompt at all, exactly as you quoted. And because the uninstall had emptied the installed-package list, that installer pops up automatically on launch. Combined with the fact that Data\Packages\{Name} is also the documented place to stage a folder for Import, this is a trap we built, not a mistake you made.

Fixes are written and in review now, targeting the next release:

• Installing over an existing non-empty folder (one-click included) now shows a confirmation with the folder's path, total size, and file count, defaults to cancel, and points at Import instead.
• The link-removal routine now refuses to delete anything that isn't actually a link. Real directories are skipped and logged, never deleted. This is pinned with tests.
• The uninstall confirmation now lists models/checkpoints for every non-symlink sharing mode and shows the package folder's total size, so a 1.37 TB deletion reads like one.
• The shared-folder toggle failures you saw as an "unobserved exception" now surface as a visible error.

Your recycle-bin and don't-overload-the-same-path suggestions are good ones and are on the list as follow-ups.

Really glad the shadow copy came through for you. If anything from the rebuild surfaces more oddities, this thread's the place, and thanks again for the rigor.