Repository navigation
1.2tb of models lost in ComfyUI Migration/Import #1733
Description
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
Activity
mohnjiles commentedon Aug 31, 2026
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'smodelssubfolders gets moved there and sorted by type:models\checkpoints→Models\StableDiffusionmodels\loras→Models\Loramodels\vae→Models\VAEmodels\controlnet→Models\ControlNetmodels\diffusion_models→Models\DiffusionModelsmodels\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
modelsfolder 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:
*.safetensors(Windows search,dir /s, or the Everything app). A move shows up immediately; 1.2 TB doesn't vanish without a trace.4. Workflows live under
Data\Workflowswhen shared (ComfyUI'suser\default\workflows\Stability Matrixis a link to it), and the sharing logic doesn't touchcustom_nodesat 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:
%APPDATA%\StabilityMatrix\Logs— plus the console output you mentioned;Data\Packagesand click Import? enable "shared model folders" on the package card? install/uninstall anything along the way?);modelsfolder (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 commentedon Aug 31, 2026
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 commentedon Sep 1, 2026
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 onC:jumped by ~1.2 TB in seconds, which is an unlink, not a same-volume move.Data\Modelswas empty afterward (model index0entries).custom_nodesanduser\default\workflowswere gone too. Onlyoutputsurvived, 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: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: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.Deletewith no reparse-point check.2. Package card started deleting the tree
3. One-click install then wiped
Packages\ComfyUIand cloned a fresh v0.34.0 over itImmediately after that, git/uv installed a clean ComfyUI
v0.34.0into the same path. Package files inData\Packages\ComfyUIare timestamped07: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\Modelswould not have freed 1.2 TB.Output “survived” only because
DeleteVerbosecorrectly removes a junction without following it, andoutputhad already been junctioned toData\Images\Text2Imgat 00:41.models\,custom_nodes\, anduser\were real directories, so they were recursively deleted.Settings at the time:
MoveFilesOnImport: truePreferredSharedFolderMethod: Configuration(ComfyUI default)RemoveFolderLinksOnShutdown: falseThe code
A. One-click install deletes whatever is already at
Packages\{Name}with no size check and no confirmation of user dataNewOneClickInstallViewModel.cs:DeleteVerbosedoes skip following junctions (that is whyoutputandweb\extensions\ComfyLiteralsonly 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 intoPackages\ComfyUIbecause 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.
RemoveLinksForPackagedoes not check that the path is a junctionSharedFolders.cs:No
IsSymbolicLink/FileAttributes.ReparsePointtest. On a real non-emptymodels\checkpointsthis throwsIOException: 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
PackageCardViewModelOnIsSharedModelSymlinkChanged/OnIsSharedModelConfigChanged: when a method is toggled off, it callsRemoveModelFolderLinks→RemoveLinksForPackage.D. Import then reconfigures shared folders
PackageImportViewModel.AddPackageWithCurrentInputsforce-recreates the venv and callsUpdateModelFolders. Combined withMoveFilesOnImport: trueand 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\Modelswas empty. Nothing was moved there.custom_nodesis not a shared-folder target, and it was deleted anyway — consistent withDeleteVerboseof the whole package dir, not with shared-folder relocation.*.safetensorsafter 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
DeleteVerbosePackages\ComfyUIin one-click install if the directory contains amodels\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.RemoveLinksForPackagemust no-op unless the path is actually a reparse point. NeverDirectory.Deletea real directory. Rename the log line; “Deleting junction target” is how people lose the other side of a link.extra_model_paths.yaml). Do not move or delete the user’s models.MoveFilesOnImportshould default off and warn when on.GetSize(includeSymbolicLinks: false)before wiping.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 commentedon Sep 1, 2026
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:
IOExceptionin 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).Data\Packages\ComfyUIwith 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 thatData\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:
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.
Merge pull request LykosAI#1379 from ionite34/fix/package-delete-guards
Merge pull request LykosAI#1381 from ionite34/backport/main/pr-1379