DEV Community

Cover image for NTROP7: a new way to manage files. Give it a try
CARLOS ENRIQUE CASTRO LAZARO
CARLOS ENRIQUE CASTRO LAZARO

Posted on • Originally published at gestor.ntrop7.com

NTROP7: a new way to manage files. Give it a try

#electron #productivity #opensource #sideprojects

I started NTROP7 about half a year ago, when I was learning how desktop apps
handle files. I was using Obsidian for everything and kept hitting the same
walls: it forces a vault-centric model, the sidebar gets noisy with hundreds
of files, and reorganizing across projects feels heavy.

So I built my own.

What it is

NTROP7 is a file manager that organizes things visually:

  • Wardrobes → top-level containers (one per project, life area, etc).
  • Books → groups inside a wardrobe.
  • Chapters → sections inside a book.
  • Files → at any level.

Each level is a real folder on your disk. There is no proprietary database;
the structure IS your filesystem. You can open the folders in your normal
file explorer and everything is where you would expect.

Why I built it

A few concrete things that bothered me with Obsidian and pure file managers:

  1. Vault lock-in: switching between projects in Obsidian means closing
    the vault and reopening another. NTROP7 lets you have multiple wardrobes
    open at once with split view.

  2. No visual hierarchy: file managers show you a list. Obsidian shows
    you a tree of .md files. I wanted a visual metaphor that made the
    structure obvious at a glance, not just nested indentation.

  3. Duplicate detection: I had hundreds of files duplicated across years
    of disorganized backups. NTROP7 has a duplicate detector that uses a
    per-project hash cache plus a real disk benchmark to pick the right I/O
    strategy (HDD / SSD / NVMe).

  4. Markdown editor that respects images: when you move a .md file,
    the image references should update automatically. NTROP7 does that.

  5. Obsidian importer: if you already have a vault, you can import it
    and keep your wikilinks working.

Stack and how it evolved

It is an Electron app: TypeScript + React on the frontend, Node main
process, lz4-napi for compression. Build with electron-builder,
hardened with Electron fuses + asar integrity validation + obfuscation.

The first prototype was rough — a single window, hardcoded paths to my
own machine, no portability. Over months I refactored it into a proper
cross-platform app:

  • Platform layer: a electron/platform/ directory with separate *-win32.ts and *-linux.ts implementations for clipboard, disk detection, disk benchmark, and unbuffered reads. A small dispatcher picks the right one at runtime.
  • Cross-platform builds: AppImage + .deb on Linux (built natively on Debian), .exe on Windows (built inside a KVM Windows VM driven via SSH from Linux).
  • EULA wired into first launch: a blocking dialog that records acceptance in userData. NSIS shows it as a license screen on Windows installs.

I built it solo and yes, with AI help — I want to be honest about that.
Most of the architectural decisions, the OS-specific work, the build
pipeline. AI helped me move faster on
boilerplate, scaffolding, and avoiding rabbit holes I would otherwise
have fallen into. The code in the asar is mine.

What it looks like

Screenshots and a video demo are on the landing.

If you want to try it:

Linux (AppImage + .deb) and Windows (NSIS .exe). 100% local. No telemetry.

Honest disclosure

This is v1.0. It works for my workflow. I have not tested every edge case
that a stranger's file system might throw at it, so:

  • If something breaks, open an issue.
  • If you have an idea or feedback, comment here or in GitHub.
  • If you find it useful, a star helps with visibility — that is genuinely the only "marketing" I am doing.

I am still learning desktop UX and there are rough edges. The point of
shipping it now is to get real-world feedback, not to wait until it is
perfect.

Give it a try. If it solves something for you, let me know.

Top comments (0)