Windows folder manager with colored Explorer folders, tray support, single-instance control, and secure encrypted vaults in development.
Implemented:
- add an existing Windows folder;
- create a new folder;
- assign a visible color/icon in Explorer;
- immediate Explorer refresh when the color changes;
- open folders quickly;
- track folders that are deleted, disconnected or restored;
- remove a folder from GeniaFolder without deleting user data;
- minimize normally to the Windows taskbar;
- close with X to keep GeniaFolder running in the notification area;
- double-click the tray icon to restore the window;
- exit the process explicitly from the tray menu;
- single-instance protection: starting GeniaFolder again restores the already-running instance instead of creating a duplicate;\n- foreground handoff: a second user-initiated launch grants the running instance permission to restore and raise its existing window.
0.2.0-alpha.1 introduces the cryptographic key foundation for Standard Protection: a random 256-bit Folder Encryption Key (FEK), PBKDF2-HMAC-SHA256 password wrapping, AES-256-GCM authenticated key wrapping, and a high-entropy paper Master Recovery Key. The folder contents are deliberately still shown as not encrypted until the file-encryption layer is enabled.
Requirements:
- Visual Studio 2026 with .NET desktop development;
- .NET 10 SDK.
Open GeniaFolder.slnx or run:
dotnet build src\GeniaFolder\GeniaFolder.csproj -c ReleaseGeniaFolder metadata is stored in:
%LOCALAPPDATA%\GeniaFolder\folders.json
Managed folders receive hidden unique icon resources such as .geniafolder-blue-<id>.ico plus an atomically updated desktop.ini. GeniaFolder retains a short history of prior icon resources so Explorer cannot fall back to the default folder while its shell cache is catching up.
- Minimize (—): normal taskbar minimize.
- Close (X): hide the window and continue in the tray.
- Tray → Exit: terminate GeniaFolder.
- Second launch: activate the existing instance.
- Force kill/crash: the operating system releases the single-instance mutex automatically; the next launch is allowed.
The future protection layer must not depend on graceful process shutdown for data security.
- random 256-bit FEK per protection profile;
- password-derived KEK using PBKDF2-HMAC-SHA256 with 600,000 iterations and a random salt;
- FEK wrapping with AES-256-GCM;
- independent 256-bit Master Recovery secret with checksum-protected GF1 recovery code;
- recovery secret is displayed before profile persistence and is never stored in plaintext;
- profile metadata is written atomically under
%LOCALAPPDATA%\GeniaFolder\protection; - both password and recovery routes are cryptographically verified before the profile can be saved;
- sensitive byte buffers are cleared with
CryptographicOperations.ZeroMemorywhere practical.
This milestone prepares keys only. Existing user files are not modified or deleted.
This milestone adds real content encryption without deleting plaintext source data:
- a separate hidden sibling vault is created next to the managed folder;
- file names and directory layout are stored only inside an encrypted manifest;
- file contents are encrypted in 1 MiB chunks with AES-256-GCM;
- each chunk uses a unique nonce and authenticated associated data bound to profile, folder, file and chunk metadata;
- reparse points/symlinks are rejected rather than followed;
- GeniaFolder-generated
desktop.iniand folder-color icon metadata are excluded from user-data encryption; - source files are opened read-only and checked for changes during migration;
- after encryption, every file is fully decrypted in memory and checked against its plaintext SHA-256;
- the encrypted manifest is authenticated and its ciphertext hash is recorded in the protection profile;
- staging data is written to a temporary directory and renamed only after full verification;
- cancellation or failure cleans the staging copy and never modifies source files.
A verified vault is still a copy in alpha.2. Plaintext activation/removal is intentionally deferred until restore testing is implemented.
The verified encrypted vault can now be restored into a new, separate folder:
- the user chooses the parent directory for the restored copy;
- the FEK is unlocked from the folder password only in memory;
- the encrypted manifest is authenticated before any restore output is trusted;
- all manifest paths are validated to prevent rooted paths,
..traversal, invalid segments and case-insensitive path collisions; - every encrypted chunk is authenticated with AES-256-GCM before plaintext is written;
- restored bytes are hashed while decrypting and must match the SHA-256 stored when the vault was created;
- restore output is written into a staging directory and published with a directory rename only after the complete restore succeeds;
- cancellation/failure cleans the staging restore and leaves the original folder and encrypted vault unchanged.
Plaintext removal is still disabled. The next security milestone should exercise recovery-key restoration and repeated crash/restore tests before activation of a vault-only mode.
The restore flow now supports two independent FEK unlock paths:
- the normal folder password;
- the offline paper Master Recovery Key (
GF1-...).
Both paths unlock the same random FEK and then feed the exact same authenticated restore pipeline. The recovery secret itself is not stored in plaintext by GeniaFolder. An invalid or unrelated recovery key fails before restoration begins.
This milestone verifies that losing the folder password does not make Standard-mode vault data unrecoverable as long as the paper Recovery Key is available.
A package-free security smoke-test runner is now part of the Windows CI pipeline. Every push builds the complete solution and exercises disposable vaults before CI can pass.
The smoke suite verifies:
- a wrong password cannot unlock the FEK;
- a modified/wrong Master Recovery Key cannot unlock the FEK;
- a normal password restore matches source files byte-for-byte;
- a Master Recovery restore matches source files byte-for-byte;
- a corrupted encrypted manifest is rejected;
- a corrupted encrypted file is rejected;
- a cancelled restore does not publish plaintext and cleans staging output;
- orphan vault staging from a simulated hard kill is cleaned on the next attempt.
These tests run only in temporary directories and never touch user vaults.
A verified Standard vault can now be promoted into a real vault-only state.
Before plaintext removal GeniaFolder:
- unlocks the FEK with the folder password;
- re-verifies the encrypted vault;
- re-reads the current plaintext tree and requires its file/directory set to match the encrypted manifest;
- hashes every plaintext file and requires its SHA-256 to match the vault manifest;
- refuses Vault-only if any file was added, removed, resized or changed after the vault was created.
The destructive transition is crash-aware:
- the protection profile enters
LockPendingbefore the source directory is atomically renamed into a sibling quarantine; - the quarantine is removed only after the verified match;
- successful completion commits
VaultOnly; - a hard kill can be resumed from
LockPendingwithout guessing what happened; - unlock restores through the same authenticated restore path and then returns the profile to plaintext-present state;
- an interrupted unlock that already published plaintext can be repaired by byte-for-byte verification rather than overwriting data.
GeniaFolder does not claim physical secure erase of SSD/NVMe blocks. Vault-only removes plaintext from the live filesystem namespace; storage-media remanence is outside this alpha milestone.
Managed folders now store the Windows filesystem identity of the directory (volume serial + file ID). If a plaintext folder is renamed in Explorer within the same parent directory, GeniaFolder can recognize the same directory and update its saved name/path automatically instead of treating it as deleted.
Legacy entries migrate automatically the next time their folder is available. Vault-only and LockPending states deliberately skip rename recovery because a missing plaintext path is expected there.
Folder identity tracking now handles more than same-parent renames:
- if a missing plaintext folder was moved directly inside another folder already managed by GeniaFolder, the app can resolve it automatically by Windows volume serial + file ID;
- missing plaintext cards with a stored identity show a
Найти…action; - manual location is accepted only when the selected directory has the exact same Windows identity;
- look-alike folders, copies and cross-volume moves are not silently rebound;
- Vault-only and LockPending still disable plaintext relocation recovery because a missing plaintext path is expected in those states.
Cross-volume moves can change the Windows filesystem identity even when the user considers the folder to be the same data. GeniaFolder no longer trusts a reappeared path when its stored volume/file ID changed.
For a protected folder with a verified vault, Найти… can validate a relocation candidate by unlocking the profile with the folder password or Master Recovery Key and comparing the complete directory/file set and SHA-256 of every plaintext file against the authenticated vault manifest. Only a complete match updates the managed path and captures the new Windows identity.
Removing a protected entry from the GeniaFolder list now requires the folder password. Vault-only and LockPending entries cannot be removed from the list until the storage transaction is returned to plaintext-present state. Removing an entry does not delete the folder, protection profile or encrypted vault.
For repeatable manual testing, RESET_TEST_ENV.cmd safely moves the current test root and local GeniaFolder app state into timestamped backup folders, then creates a fresh D:\GeniaFolder test\Папка 1, Папка 2 and Папка 3.
GeniaFolder now uses one paper Master Recovery Key per local installation.
- The first protected folder creates a random 256-bit Master Recovery secret and shows the GF1 paper key once.
- The Master secret itself is never stored. GeniaFolder persists only a SHA-256 verification hash/fingerprint.
- Every protected folder still gets its own random 256-bit FEK and its own user password.
- Each folder derives a different recovery KEK from the shared Master secret using HMAC-SHA256, a per-profile random salt, and the FolderId.
- Later folders require the same paper Master Recovery Key during protection setup; a new paper key is not generated.
- The same Master Recovery Key can recover every folder enrolled under that installation, while each folder password remains independent.
- Minimum folder password length is now 8 characters; the UI recommends 12+.
Folder location recovery now searches the last known parent and a bounded chain of ancestor directories, in addition to known managed folders. Each search root is checked only at the direct-child level; GeniaFolder still does not recursively scan an entire drive.
This fixes the round-trip case where a tracked folder is moved into another managed folder, adopted at the nested path, and later moved back to its original parent. The stable Windows volume/file ID is used to prove identity before the registry path is updated.
Moving a directory between volumes is a copy/delete operation from the filesystem identity perspective. Returning it to the original path therefore does not restore the old Windows file ID.
GeniaFolder now treats an existing registered path with a changed identity as a cross-volume return candidate:
- unprotected entries automatically adopt the new Windows identity when they reappear at the exact registered path;
- protected entries fail closed and show a Verify action instead of appearing simply lost;
- if a verified vault exists, the candidate must be authenticated with the folder password or installation Master Recovery Key and match the encrypted manifest/file SHA-256 set before the new identity is persisted;
- if protection keys exist but no verified vault has been created yet, explicit folder-password authentication is required before rebinding.
Security smoke tests recreate a folder object at the same path with identical bytes but a new Windows file ID to simulate D: -> E: -> D: behavior.
Folder tracking no longer relies only on the Windows volume/file ID. Managed plaintext folders receive a hidden/system .geniafolder.id marker containing the GeniaFolder folder ID. Explorer copy/move operations preserve the marker across volumes, while Windows may assign a new filesystem identity. Confirmed previous locations are also retained in the registry, and parents of other managed folders are used as bounded search anchors. A protected folder found by marker is treated as a candidate and still requires explicit cryptographic verification before a new Windows identity is trusted.
Убрать now removes GeniaFolder-owned desktop.ini and generated folder icons before deleting the card, while preserving .geniafolder.id. Re-adding the same physical folder therefore reconnects its stable GeniaFolder ID/profile instead of creating an unrelated identity, and color customization starts cleanly.
Master Recovery setup is now installation-level and separated from folders. On a fresh GeniaFolder state, the app creates and displays the paper Master Recovery Key before the main window is shown. Folder creation/addition never generates a paper key. The main window has a separate Master Key control that shows its fingerprint/status; the secret itself is not stored in clear text and cannot be re-displayed.
Folder color changes no longer overwrite or immediately replace a single fixed icon resource. Every application publishes a unique .geniafolder-<color>-<id>.ico, then atomically switches desktop.ini to that resource. A bounded history of previous generated icons is retained temporarily because Explorer can continue reading a cached older desktop.ini after a color change.
Appearance changes are serialized so rapid color selections cannot finish out of order. GeniaFolder explicitly applies the Windows shell customization attributes to the directory and notifies both the folder item and its parent view. Removing a managed entry still removes all GeniaFolder color metadata while preserving the stable .geniafolder.id tracking marker.
The Windows smoke suite now applies two different colors sequentially and verifies that each desktop.ini references a distinct existing icon resource, the previous icon is retained for cache safety, and cleanup removes all color resources without deleting the tracking marker.
Explorer color customization now follows Microsoft's documented Desktop.ini format for filesystem folders: IconFile=<relative .ico> plus IconIndex=0. GeniaFolder still publishes a unique icon resource for every color change, writes the Unicode desktop.ini atomically, marks it hidden/system, enables folder customization with PathMakeSystemFolder, retains a short history of prior icon files for cache safety, and invalidates Explorer's shell icon cache after the update.
Changing a folder color now refreshes not only Shell metadata and icon caches but also any open File Explorer window currently showing the folder or its parent directory. GeniaFolder performs best-effort Shell COM refreshes immediately and again after short delays, while also sending change notifications for the new icon file, desktop.ini, the folder itself and its parent. This replaces the manual repeated-F5 workaround observed on some Windows Explorer sessions.
Before deleting plaintext, the source directory is moved into a sibling quarantine recorded in the profile as LockPending; the quarantined data is verified against the authenticated vault again. If that verification fails, the entire quarantine is moved back to the original path and the profile returns to PlaintextPresent. Only after successful verification is the durable DeletionCommitted state written, which permits resuming partial deletion after process termination. An uncommitted missing plaintext+quarantine combination is now treated as an error, not as success.
The registry now serializes reads and writes and uses unique atomic staging files. Conflicting managed-folder ancestor/descendant protection is rejected and missing folder markers are not stamped into known-identity mismatches. Master Recovery entry in the vault restore/verification window is hidden, relocation verification uses its own headings, and the lock UI receives an explicit non-cancellable-phase signal.
Security smoke tests cover registry concurrency, overlapping folder detection, changed quarantine rollback, and a simulated hard kill during committed deletion. These tests are not a substitute for checking Explorer caching or live concurrent writers; continue testing with disposable data.