kiftd: a self-hosted network disk, and the source behind the release

The source repository and the product it builds

kiftd is described as a convenient, open source, feature-complete network disk server system for a person, a team or a small team. This repository is where the source lives, and the README is explicit about its relationship to the released software: the repository is also the development repository, so its version may be ahead of the release, but it is never behind it.

That relationship is the first thing to understand. The code here is the origin of the ready-to-run build that the author distributes separately, and the README says the two stay consistent, with the source occasionally slightly ahead.

The version at the time of writing is v1.2.3-SNAPSHOT, which is what a development branch looks like rather than a release. There are no GitHub releases for the project, and the release artefact is the compiled archive on the official homepage at kohgylw.github.io.

The README also points out what kind of reader this repository is for. It says the source will be gradually organised over time to make it easier to read, and apologises for the inconvenience that causes. That is an unusual and honest thing to say in a README: this is a codebase published in the hope that people will read it, and the author is telling you up front that the tidying is a work in progress.

A third-party licence package inside the source tree, the third-party tool licences package, points the same way. The project ships its own licence terms and gathers the licences of the tools it uses in one place.

JDK 1.8, Maven, Spring Boot, MyBatis and H2

The build environment is specified in a short list, and it is worth reading carefully because two of the entries date the project.

The JDK version is 1.8.0. The project management framework is Maven, with m2e 1.8.0 for Eclipse, and the archetype is mavem-archetype-quickstart 1.1. The encoding is UTF-8. And the project resources and configuration are Spring Boot with MyBatis and an H2 database, with the details in pom.xml.

The stack is a common Java application stack for its era. Spring Boot for the application framework, MyBatis for the data access layer, and H2 as the embedded database, which means there is no database server to run and the state lives in a file.

The JDK 1.8 requirement is the constraint to plan around. Java 8 is no longer the baseline most organisations build on, and a project pinned to it will not compile on a modern JDK without changes to the build configuration, and the Spring Boot version in the pom will have its own constraints. The README recommends this configuration for reading and compiling the source, so it describes what the author used rather than a hard requirement of the code.

The H2 database is worth a note for anyone planning to run this in anger, since an embedded file-backed database is convenient for a household server and is not what most production deployments use.

Five steps, and one trap that catches everyone

The quick start is written for Eclipse, and it is a sequence of IDE actions rather than shell commands.

You import the source folder into Eclipse, Java EE edition, as a project, and set the JDK version in the build path. You update the project using the Maven options, making sure that all the external resources referenced in the pom are pulled in locally. You open the class kohgylw.kiftd.mc.MC and run it to test. Then you right-click the project, choose Run with and Maven install, which compiles a jar into the target folder. Finally you copy that jar into the project main directory, alongside the libs folder, and start using it.

The last point is the unusual one, and it explains the final step. The jar is not self-contained in the way a modern fat jar would be, so it needs the sibling libs directory next to it to run.

The tip in the README is about the resource handling, and it is the single most useful warning in the document. The source path contains non-source resources the program needs at runtime, such as the application icons, and some IDEs, IDEA named explicitly, silently ignore those files while building, so they never make it into the jar. The result is a build that succeeds and a program that will not start.

The FAQ repeats the point for IDEA users specifically, with the fix being to change the IDE settings so that all files under the source path are recognised and packaged rather than only the ones it considers source.

The package layout is a map of the application

The README lists the structure of the program, and the list reads as a description of what the software does.

The source folder is /src/main/java/, and the entry class is kohgylw.kiftd.mc.MC. The web request handling packages are kohgylw.kiftd.server.controller and kohgylw.kiftd.server.filter, and the web operation logic is in kohgylw.kiftd.server.service. The core functionality and file system implementation sits in kohgylw.server.util, kohgylw.kiftd.server.listener, kohgylw.kiftd.server.mapper and kohgylw.kiftd.server.model, and the server behaviour control class is kohgylw.server.ctl.KiftdCtl. The interface-related packages are kohgylw.kiftd.ui and kohgylw.kiftd.printer, and there is a standalone file management module in kohgylw.kiftd.util.file_system_manager.

The directories outside the source tree are equally informative. The web page static resources are in /webContext/, the MyBatis mapping tables in /mybatisResource/, external referenced resources generated after the build in /libs/, referenced fonts in /fonts/, the settings folder in /conf/ which is generated after the first run, logs in /logs/, and the build output in /target/. The top-level listing also shows a filesystem/ directory and a TODO.txt.

The pattern worth noticing is that the runtime state, the configuration and the logs are all separate directories that the program creates for itself. That is what makes the distribution model work, since the jar can be dropped anywhere and the state accumulates beside it.

The two FAQ entries are the real friction

The troubleshooting section has two entries, and they are the most informative part of the README for anyone who intends to build this.

The first is the IDEA problem described above, where the IDE ignores non-source files in the source path and the resulting jar lacks the icons the interface needs. The fix is to change the IDE settings so everything under the source path is packaged.

The second is a startup failure with the message Error creating bean with name org.mybatis.spring.mapper.MapperScannerConfigurer. The fix is to remove the mybatis and mybatis-spring resources from pom.xml and add the mybatis-spring-boot-starter resource instead, to avoid the compatibility problem the default integration can cause with the Spring Boot plugins. The README credits a user named michael for that answer.

Both are the kind of entry that saves an afternoon, and both are the kind of entry that usually does not survive into a project's documentation, because they are answered in a forum post instead. Their presence here is a small mark of how the project is maintained.

The TODO.txt in the repository root suggests the same thing. This is a project with a known list of outstanding work, published alongside the code.

Where kiftd is the wrong choice

The first wrong-tool case is a team that wants a supported product rather than a codebase. The README itself points people who only want working software to the compiled release on the official homepage, which the author says can be installed and used within three minutes. If your requirement is a working file server, that is the answer, and the source repository is not the shortcut.

The second is a deployment that has to survive an audit of its licensing. The project uses its own licence file, distributed with the release, and the README lists the terms: you may obtain a free copy of the original source, you may distribute, refactor and use it in any field, the author is not responsible for any consequences, and the author holds the copyright. A licence of that kind is workable for a personal project and is not the sort of licence a corporate legal team will wave through without reading the file, and the source repository itself records no licence identifier at all.

The third is a modern Java shop. JDK 1.8, an old archetype, an Eclipse-centric workflow and an embedded H2 database are all coherent for a project that has been maintained by one person, and all awkward for a team with a current toolchain, a containerised deployment story and a database migration policy.

The fourth is a large file share. This is described as a personal, team or small-team network disk, and a file server built for a household is not a distributed storage system with replication, quotas at scale or an audit trail.

A custom licence, a snapshot version, and a June 2026 push

The licence situation is the one to read carefully. The README says the current version of kiftd is distributed with its own licence file, that you should obtain that file by downloading a release from the kiftd release page, and that the terms are summarised in the README as the four points above. The project licence field on the repository is recorded as unknown, so the licence file inside a release is the authoritative document.

On versions, the repository shows v1.2.3-SNAPSHOT, a Maven snapshot identifier rather than a release number, and there are no GitHub releases. The default branch is master, and the last push was on 2026-06-14, with the README itself dated the following day.

The activity picture is therefore modest but recent. A project that is being tidied up for readers, with a TODO list and a note about ongoing organisation, is not a project in decline, and the contact address in the README is a personal mailbox rather than a tracker or a forum.

For anyone who wants to start from this code, the practical sequence is short. Read the licence from a release, clone and build with the JDK and Maven versions the README names, make sure your IDE packages the resources, and then treat the project as what it is, a working, readable, self-hosted file server that one developer publishes in the hope that other people will find it useful and improve it.

Editorial conclusion

Adopt kiftd-source if you want to read, run or extend a self-hosted file server and are comfortable with Java, Maven and an H2 database, and treat it as a starting point for a fork rather than a dependency to pin. Do not adopt it if you want a finished product, since the author points people who only need working software to the ready-to-run build on the official homepage, and do not adopt it if your organisation requires a recognised open source licence, because the project ships its own licence terms and the source repository records none. Before you build, read the licence file from a release, check the JDK 1.8 requirement against your toolchain, and make sure your IDE packages the non-source resources, since that is the single most common way this build fails.

Frequently asked questions

Official sources

1. Issues
2. KOHGYLW/kiftd-source on GitHub
3. README