TBlog

tdrive

Sun, 28 Jun 2026 00:00:00 GMT

tdrive

#go #self-hosted #file-server #webdav #ftp

Turn any directory into a private web drive with HTTP, WebDAV, and FTP access — one static binary, no database.

tdrive turns an ordinary directory into a personal file service. Point it at a folder, start one binary, and the same files are immediately available through a polished web interface, WebDAV, optional FTP, and a REST API.

There is no database to migrate, no configuration file to maintain, and no frontend toolchain to install. Your files stay as normal files on disk, so backups, scripts, editors, and command-line tools can keep working with them directly.

A lightweight drive that still feels complete

The browser interface is designed for everyday file work rather than being a thin directory listing:

Filter the current folder instantly, sort by column, and switch between list and thumbnail grids.
Upload from the toolbar or drag files into the browser. Large uploads are chunked, while downloads stream with HTTP range support.
Preview images and HTML, and render Markdown with GFM, Mermaid, KaTeX, and syntax highlighting.
Edit text files in place, create folders and files without modal dialogs, and use familiar keyboard shortcuts.
Select multiple entries for batch operations, drag items between folders, or use the context menu to rename, delete, download, and copy a raw URL.
Switch the interface between 中文 and English.

One directory, several access methods

Every interface operates on the same filesystem tree:

Interface	Address	Best for
Web UI and HTTP	`http://host:3000/`	Browsing, previewing, editing, and sharing links
WebDAV	`http://host:3000/webdav/`	Mounting the directory in an OS or file manager
FTP	Enabled with `--ftp-port`	Existing FTP clients and LAN workflows
REST API	`/api/v1`	Scripts and integrations
Raw files	`/raw/<path>`	Stable direct URLs and nginx-style folder indexes

The storage layer is confined with Go’s os.Root: path traversal and symbolic links cannot escape the directory you chose to serve. A read-only mode can disable every upload, edit, move, and delete operation across all protocols.

Start in seconds

Serve the current directory on port 3000:

tdrive

Serve a dedicated folder and require a password:

tdrive /srv/files --port 3000 --password "choose-a-strong-password"

Add FTP access for clients that need it:

tdrive /srv/files --password "choose-a-strong-password" --ftp-port 2121

For a local-only workspace, bind it to the loopback interface:

tdrive ~/files --host 127.0.0.1

By default tdrive listens on all interfaces without authentication. Set --password, use --host 127.0.0.1, or place it behind an authenticated HTTPS reverse proxy before exposing it outside a trusted network.

Where it fits

tdrive is useful when a full NAS platform is more machinery than the job needs: a private download box, a temporary project share, a small home-server drive, a browsable folder on a development machine, or a read-only archive with clean direct links.

The current release provides native amd64 packages for Windows and Linux. Source code, issue tracking, and release history are available in the tdrive GitHub repository.

windbg-ctype

Mon, 15 Jun 2026 00:00:00 GMT

windbg-ctype

#windbg #windows #reverse-engineering #c

A WinDbg extension that parses C headers and dumps memory as those types — like dt, but for types that were never in any PDB.

Windows amd64 Windows i386

dt is one of the most useful commands in WinDbg, but it only knows the types that are baked into the loaded PDBs. The moment you are staring at memory whose symbols you do not have — a third-party driver, an undocumented OS structure, a packet you only have a header for — dt has nothing to say.

windbg-ctype closes that gap. You give it a C header, it parses the declarations itself, and from then on you can walk memory through those types exactly the way dt walks symbol types — even though the debugger has never seen a matching PDB.

What it does

The extension carries a small C parser. !loadc reads a header, resolves the type layout (the same rules the compiler would apply), and registers every struct, union, enum, and typedef it finds. After that:

!dt prints a type the way the built-in dt does — field names, offsets, and the WinDbg type of each field; pass an address and it reads and prints the values there too. The layout output matches WinDbg’s own dt for the same type, so it drops straight into the workflow you already have.
!dtc prints the type back as a C declaration, optionally annotated with offsets, which is handy when you want to paste a struct into your own code or sanity-check what the parser actually understood.

It handles the parts of C that real headers actually use: nested structs and unions, anonymous members, bitfields, fixed arrays, pointers and function pointers, enum-typed fields, #pragma pack, and explicit alignment via __declspec(align(N)) or alignas(N). Include directories (-I) and preprocessor defines (-D) are passed through, and -p<N> overrides the default pack so you can match whatever the target was compiled with.

Anything it does not own — a module-qualified name like nt!_EPROCESS, a wildcard, or a type it never loaded — is forwarded to the built-in dt, so you never lose the normal behaviour by having the extension loaded.

Commands

!loadc <path> [-p<N>] [-I <dir>]... [-D NAME[=VALUE]]...   load a header
!listc                                                     list loaded types
!clearc                                                    drop all loaded types
!dt [opts] <type> [field] [address]                        dt-style listing
!dtc [-v] <type> [address]                                 C declaration output
!help                                                      reference + build info

Example

Say you have this header:

// C:\headers\types.h
struct Scalars
{
    char c;
    unsigned char uc;
    short s;
    unsigned short us;
    int i;
    unsigned int ui;
    long long ll;
    float f;
    double d;
    void* p;
    wchar_t w;
};

struct Bits
{
    unsigned long a : 1;
    unsigned long b : 2;
    unsigned long c : 5;
    unsigned long d : 24;
};

Load the extension, load the header, and list a type:

0:000> .load C:\tools\ctype\ctype.dll
0:000> !loadc C:\headers\types.h
!loadc: loaded 2 type(s) from file:C:\headers\types.h (target pointer_size=8)

0:000> !dt Scalars
   +0x000 c                : Char
   +0x001 uc               : UChar
   +0x002 s                : Int2B
   +0x004 us               : Uint2B
   +0x008 i                : Int4B
   +0x00c ui               : Uint4B
   +0x010 ll               : Int8B
   +0x018 f                : Float
   +0x020 d                : Float
   +0x028 p                : Ptr64 Void
   +0x030 w                : Wchar

The offsets are the real layout the compiler would produce — note how ll lands at +0x010 after the 4-byte padding behind ui. Bitfields are reported the same way dt reports them:

0:000> !dt Bits
   +0x000 a                : Pos 0, 1 Bit
   +0x000 b                : Pos 1, 2 Bits
   +0x000 c                : Pos 3, 5 Bits
   +0x000 d                : Pos 8, 24 Bits

!dtc prints the same type back as a C declaration, with -v adding the offset of each field:

0:000> !dtc Scalars
// size is 0x38 (56)
struct Scalars
{
    char           c;
    unsigned char  uc;
    short          s;
    unsigned short us;
    int            i;
    unsigned int   ui;
    long long      ll;
    float          f;
    double         d;
    void*          p;
    wchar_t        w;
};

Pass an address after the type name (!dt Scalars <address>) and it reads and prints the values living there, just like dt.

Requirements

Windows, with the Debugging Tools for Windows (WinDbg / cdb / kd).
The DLL architecture must match the debugger architecture: load the amd64 build in 64-bit WinDbg and the i386 build in 32-bit WinDbg. Loading the wrong one fails with an architecture-mismatch error.
No network access and no symbol server are involved — the only input is the header you point it at.

Install

Unzip the build for your debugger’s architecture and load ctype.dll from wherever you put it:

.load C:\tools\ctype\ctype.dll
!help

!help prints the version, the commit it was built from, and the command list, so you can always tell which build you are running.