YanWenKun / ComfyUI-Windows-Portable

🎨ComfyUI standalone pack with 30+ custom nodes. | ComfyUI 大号整合包,预装大量自定义节点(不含SD模型)
GNU General Public License v3.0
97 stars 14 forks source link

Revert all System Changes #15

Open ZenRevision opened 5 days ago

ZenRevision commented 5 days ago

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_WindowsPortable 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 commented 3 days ago

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.