From bf7a57fc55493247a624ecfd65e4d73964e7d8d2 Mon Sep 17 00:00:00 2001 From: SulfurNitride Date: Sun, 12 Apr 2026 02:40:16 -0500 Subject: Remove vendored usvfs and Windows-only usvfs code paths The Linux port uses its own in-process FUSE VFS (FuseConnector), so usvfs was dead weight: libs/usvfs/ was never built, usvfsconnector.cpp was explicitly REMOVE_ITEM'd from the source list, and every call site was already guarded by #ifdef _WIN32 with a working Linux branch (the Windows build is also broken on this branch, since FUSE3 is a hard find_package dependency). - Drop libs/usvfs/ and src/src/usvfsconnector.{cpp,h} - Collapse #ifdef _WIN32 / usvfs include branches in organizercore, mainwindow, settings, util, spawn - Remove getUsvfsVersionString() and the "usvfs: ..." log field - Remove vfs32/64DLLName APPPARAMs (nothing reads them) - Relabel About dialog "usvfs:" row to "VFS: FUSE 3" --- libs/usvfs/README.md | 59 ---------------------------------------------------- 1 file changed, 59 deletions(-) delete mode 100644 libs/usvfs/README.md (limited to 'libs/usvfs/README.md') diff --git a/libs/usvfs/README.md b/libs/usvfs/README.md deleted file mode 100644 index 1167810..0000000 --- a/libs/usvfs/README.md +++ /dev/null @@ -1,59 +0,0 @@ -# USVFS - -[![License](https://img.shields.io/:license-gpl-blue.svg)](http://www.gnu.org/licenses/gpl-3.0.en.html) -[![Build](https://github.com/ModOrganizer2/usvfs/actions/workflows/build.yml/badge.svg)](https://github.com/ModOrganizer2/usvfs/actions) - -USVFS (short for User Space Virtual File System) aims to allow windows applications to -create file or directory links that are visible to only a select set of processes. -It does so by using api hooking to fool file access functions into discovering/opening -files that are in fact somewhere else. - -## Current state - -USVFS is work in progress and should be considered in alpha state. -It is a core component of Mod Organizer v2 -and thus receives serious real world testing. - -## Building - -You will need `cmake`, Python 3+ and `vcpkg` to build USVFS: - -```pwsh -cmake --preset vs2022-windows-x64 -cmake --build --preset vs2022-windows-x64 --config Release - -# only if you need to hook x86 applications -cmake --preset vs2022-windows-x86 -cmake --build --preset vs2022-windows-x86 --config Release -``` - -## Comparison to symbolic links - -The following is based on the final goal for USVFS and doesn't necessary reflect the -current development state. - -Unlike symbolic file links provided by NTFS - -- links aren't visible to all applications but only to those the caller chooses -- links disappear when the "session ends" -- doesn't require write access to the link destination -- doesn't require administrator rights (neither for installation nor for use) -- links are filesystem independent so you can create links on fat32 drives, read-only media and network drives -- can link multiple directories on top of a single destination (overlaying) -- can also "virtually" unlink files, thus make them invisible to processes or replace existing files - -There are of course drawbacks - -- will always impose a memory and cpu overhead though hopefully those will be marginal -- becomes active only during the initialization phase of each process so it may not be active at the time dependent dlls are loaded -- introduces a new source of bugs that can cause hard to diagnose problems in affected processes -- may rub antivirus software the wrong way as the used techniques are similar to what some malware does. - -## License - -USVFS is currently licensed under the GPLv3 but this may change in the future. - -## Contributing - -Contributions are very welcome but please notice that since I'm still undecided on -licensing I have to ask all contributors to agree to future licensing changes. -- cgit v1.3.1