Revert all System Changes

[ZenRevision]

Thanks for putting this together! Awesome project!

The Issue

So I accidentally ran run_nvidia_gpu.bat just after initial extraction, un-sanboxed.

Unfortunately this portable setup is not very portable by default (I realize this is an issue with ComfyUI_Portable in general and not specific to the this particular version).

I know it added C:\Users\CurrentUser\.u2net\u2net.onnx because that gets logged. I'm wondering though if it added anything else that wasn't logged, or that I'm not seeing in the log due to my own limited understanding.

When I was using it previously (always sandboxed), it seemed like there were numerous changes to files on C: as well as registry changes (that could be seen in the sandbox contents), that were not always obvious in the logs. That was after many runs though, and the installation of several additional custom node packages. I'm not sure about immediately after first run (wasn't paying close enough attention before -- and this time, the first run was accidentally outside the sandbox).

Ideally I'd like to fully revert any and all changes to the C: drive and the registry caused by the first run of run_nvidia_gpu.bat. Can anyone shed any light on this?

Yes, I realize that I could run it in a clean virtual machine, or a freshly extracted setup in a clean sandbox -- unfortunately though, I'm not well versed in comprehensively tracking/mapping changes within a virtual machine, and even the contents of Sandboxie sandboxes can elude my complete understanding when the contents are anything beyond simple file additions, such as file edits or registry edits.

Suggestions

1. Simple Solution: It would be great if all changes outside of the ComfyUI_Windows_Portable directory, caused by running the default setup, could be fully documented.

2. Better Solution: A script could be provided to automatically revert all such changes.

3. Best Solution: A separate logging system that only tracks file and registry changes. This could store all changes to the system, and categorize them according to time, session number, and context. So one could easily differentiate between changes made on first run, and 5th run -- or between changes made within the ComfyUI_Windows_Portable directory, and changes made outside that portable context -- or between file additions, edits, deletions, and registry edits.

4. Ultimate Solution: A script which could leverage the comprehensive logging described above, to revert changes based on custom criteria. For example; fully revert all changes since initial setup, or fully revert only changes from the last 3 runs, or fully revert only changes outside of portable context for all except the first run, etc..

5. Perfect Solution: Transparently redirect all changes targeting anything outside of the portable context to a portable substitute. Basically doing what Sandboxie does, except by default.

Rationale

Portable apps, ideally, strictly limit any changes to the system outside of their portable context. Given that ComfyUI_Portable makes changes to the system outside of it's portable context, it would be helpful if such behavior could at least be well documented and easily reversible.

[YanWenKun]

The cache files outside ComfyUI folder were created by the Custom Nodes. In my observation, the ComfyUI "core" was pretty clean and elegant. But yeah, Custom Nodes are this package all about.

For a simple operation, just clean these folders under %USERPROFILE%:

.u2net
.matplotlib
.cache\huggingface
.cache\torch

AppData\Roaming\Ultralytics
AppData\Local\torch_extensions
AppData\Local\pip

For future improvements, I guess the environment variables, such as %USERPROFILE%, %HOMEPATH%, could be used to redirect file storage. But side effects are very likely to happen, more testing is needed.

For registry, by using regshot inside sandbox (RegistryChangesView won't work in sandbox), I see no meaningful changes to concern about. Python software, considering cross-platform, rarely uses Registry, since it's Windows-only. And if it does, it become very conspicuous.

For complete sandboxing, I have no idea other than Sandboxie. But Sandboxie itself is not portable software, I can't bundle it. So for now it's ultimately depends on users.

[YanWenKun]

Bad news, setting %HOMEPATH% has no effect, and setting %USERPROFILE% will (with no surprise) cause error:

python_embeded\Lib\site-packages\torch\_appdirs.py, line 336, in user_cache_dir
    path = os.path.normpath(_get_win_folder("CSIDL_LOCAL_APPDATA"))

So I guess sandboxing everything via scripts is not a good idea. Sandboxie is still the go-to option for jailing cache files.

[ZenRevision]

Thanks for looking into that!

How about about option 3 from above? A separate logging system that only tracks file and registry changes caused by anything launched via the ComfyUI script?

I imagine that may be much harder to implement than it sounds, but do you think it is possible?

Thank you so much for setting up this version of ComfyUI. Every time I've setup ComfyUI, there has been a range of minor obstacles and gotchas which are easy to get tripped up by. So this is a godsend, as it seems to have effectively filled almost all of those potholes! The proxy config in the .bat is a great addition too. Fantastic job!

[YanWenKun]

Glad you enjoy it!

I have several notes for you:

1. Add --verbose to ComfyUI args to track more activities.

2. Use ProcMon from Sysinternals to track every changes a process have made.

3. Running apps in another Windows user (and even in Sandboxie) would prevent apps accessing main user's file. And ComfyUI runs as a web sever, so you can just open the browser in main user to use ComfyUI.

4. Using Docker for clean isolation, that prevents apps accessing system/user files. But running ComfyUI in WSL2 Docker is not performant as native Windows one.

5. Snapshots on process-level require sandboxing, currently I don't know any "portable framework" to do this.

6. Logging could also be done by modifying ComfyUI's python code to introduce debugging and tracing. Or just use IDE's debugging. But it could be a mess since the all-in-one bundle is so big, and you probably don't want to look into every lines.