Skip to content

SpaceKnife 0.3.4

Pre-release
Pre-release

Choose a tag to compare

View all tags
@github-actions github-actions released this 26 Oct 01:58
· 309 commits to main since this release
v0.3.4
This tag was signed with the committer’s verified signature.
DuskXi
GPG key ID: 484D4986A39BF710
Verified
Learn about vigilant mode.
d50a09b
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

English · 简体中文 · Website · Documentation

SpaceKnife 0.3.4 (pre-release)

A disk usage analyzer that shows what fills your drives, on Windows, Linux and macOS. SpaceKnife is an independent project inspired by SpaceSniffer and is not affiliated with SpaceSniffer or its author.

This is a pre-release. Windows and Linux builds are not code-signed; the macOS builds are ad-hoc signed, not notarized.

Every file was built and checked by GitHub Actions: run 40255561003.

Download

System File Size
Windows 10+ x64 SpaceKnife-0.3.4-Setup-x64.exe 137 MB
Windows 10+ x64, portable SpaceKnife-0.3.4-win-x64-portable.zip 175 MB
Windows 11 on ARM, portable (new) SpaceKnife-0.3.4-win-arm64-portable.zip 171 MB
macOS 14+, Apple Silicon SpaceKnife-0.3.4-mac-arm64.dmg 141 MB
macOS 14+, Intel SpaceKnife-0.3.4-mac-x64.dmg 148 MB
macOS 14+, Apple Silicon, portable (new) SpaceKnife-0.3.4-mac-arm64-portable.zip 141 MB
macOS 14+, Intel, portable (new) SpaceKnife-0.3.4-mac-x64-portable.zip 148 MB
Ubuntu 22.04+ / Debian family spaceknife_0.3.4_amd64.deb 132 MB
RHEL 9+ / Fedora family spaceknife-0.3.4.x86_64.rpm 119 MB
Other Linux x64 SpaceKnife-0.3.4-x86_64.AppImage 164 MB
Linux x64, portable SpaceKnife-0.3.4-linux-x64-portable.tar.gz 162 MB
Linux arm64, portable (new) SpaceKnife-0.3.4-linux-arm64-portable.tar.gz 160 MB
  • From 0.3.3: click the badge at the top right; the card downloads the file for your installation, checks its SHA-256 and offers Seamless update or the classic way. Snapshots and settings stay.
  • Windows: run the new installer over the old one. It is unsigned: SmartScreen › "More info › Run anyway".
  • macOS: drag into Applications; on first launch, System Settings › Privacy & Security › "Open Anyway" (steps).
  • Linux: deb / rpm go to /opt/SpaceKnife (command spaceknife). The AppImage needs FUSE 2 (libfuse2) or --appimage-extract-and-run; AppImageUpdate updates it in place (the .zsync file is attached).
  • Portable: unzip anywhere; everything is kept in data next to the app. To upgrade by hand, replace all but data.
    • New on macOS: unzip, open SpaceKnife.app and keep it next to its data folder. It is not notarized: allow it once in System Settings › Privacy & Security, as for the dmg.
    • New for ARM: Windows 11 on ARM and Linux arm64; the installers stay x64. An x64 portable copy on Windows on ARM moves to the ARM build at its first update after 0.3.4; to switch now, copy its data folder into the unzipped ARM portable.
  • Checksums: SHA256SUMS.txt (installers), SHA256SUMS-portable-*.txt (Windows and Linux portables), SHA256SUMS-mac-*.txt (dmg and portable, one file per chip).

What's new

  • Light theme. SpaceKnife follows your system's light or dark setting by default (Settings › Appearance › Theme: Match system, Light, Dark); the treemap, the flame graph and the polar flame graph switch with it at once, without a white flash, and headless mode follows the browser. Class colors you pick in Settings › File classes apply to the current theme, or to both with Also apply to the other theme; colors chosen before 0.3.4 stay in both.
  • Portable versions for ARM: Windows 11 on ARM and Linux arm64, used just like the x64 ones. The installers stay x64.
  • A portable version for macOS (Apple Silicon and Intel). Snapshots and settings stay in the data folder next to SpaceKnife.app, nothing goes to your Library, and the app still finds that folder when macOS runs it from a hidden copy (App Translocation). Seamless update works for it as for the Windows and Linux portable versions.
  • Disks remembers each volume's last complete scan: its file classes, largest folders, counts and scan time stay after you leave the page, close the tab, reload or restart, until the next complete scan. Only the same volume (drive letter or mount point, plus volume serial) gets them back.
  • A File classes bar on Disks adds up the classes of every volume with a known mix, with each class's size and share and the volumes it covers.
  • Visualizations help page (docs): how the treemap, the flame graph and the polar flame graph each organize the picture, side by side in a table, with a picture of each. The polar flame graph reads like a stacked pie chart with no center: each ring is a folder level, the angle is the share.
  • Keep large scans in mapped files (Settings › Advanced › Memory, off by default). Scans of more than about two million items keep their data in memory-mapped files in the cache folder, which the system can drop from RAM at any time. On 3.2 million items the backend settles at about 250 MB instead of 600 MB and peaks at about 400 MB instead of 750 MB, at the same speed; the cost is a one-time write of about 200 bytes per item after the scan (about 1.8 GB for 8.6 million items).
  • scan --mft on the command line reads a whole local NTFS drive's $MFT, like the app's MFT quick scan (Windows; asks for administrator rights once; off by default). A folder, another file system, a network drive, several paths or a refused prompt fall back to a folder-by-folder scan after a line saying why; the result says how the drive was read.

Fixes

Security

  • Compromised eMudhra certificates are refused. In October 2026 it came out that the private keys of eight intermediate certificates of eMudhra, an Indian certificate authority, had been generated wrongly in 2025 and could be worked out from the public certificates; Firefox, Chrome, Apple and Microsoft blocked them on 17–20 October. SpaceKnife now ships Electron 44.9.3, which refuses them, and the update check (it connects only to GitHub) now lets Windows and macOS verify certificates, so anything the system blocks is refused too. The window shows only the app's own pages and makes no connections of its own, so it was not exposed. On Linux, keep ca-certificates up to date.

Faster scans

  • Hard scans choose how many folders to list at once, from the CPUs SpaceKnife may use (CPU affinity and container quotas now count) and whether folders must come from the disk; the disk load limit still holds. On NVMe with the cache emptied, an NTFS drive of 1.9 million items takes 7.7 s instead of 11.4 s and a ReFS drive of 3.2 million items 22 s instead of 35 s; in memory, the NTFS drive takes 2.1 s instead of 2.6 s with 17% less CPU time.
  • Windows hard scans open each folder from its parent instead of from the drive's root (NTFS, ReFS, WinBtrfs; each checked by file ID). In memory, a ReFS drive of 3.2 million items: 5.2 s → 3.8 s; an NTFS system drive of 8.8 million items: 13.1 s → 12.6 s.
  • The tree is built natively while listing carries on: a warm scan of a 770,000-item Linux system 0.34 s → 0.26 s; C:\Users with 7.7 million items, read from the disk, 15.8 s → 14.9 s.
  • Hard links are counted natively: a warm scan of a 600,000-item Linux system with 160,000 hard links (uv's cache and virtual environments) 0.37 s → 0.29 s.
  • Sparse and compressed files no longer slow Windows hard scans: on local NTFS, ReFS and WinBtrfs drives, size on disk now comes from the folder listing instead of opening each such file (12.8 s of a cold benchmark scan). Small files kept inside their NTFS record (about 513–700 bytes) or inline on ReFS (under about 1.5 KB) now take 0 bytes on disk instead of a cluster, as in the MFT quick scan.
  • MFT quick scans are about four times faster: 8.9 million items in about 4.7 s instead of 19 s (reading 7.2 s → 2.8 s, building the tree 12 s → 0.4 s). The reads in flight adapt to the drive, so a SATA SSD isn't flooded and NVMe gets more, and a load limit is kept. Same result, item for item.
  • Command-line scans start and end faster: an empty folder takes 220 ms instead of 410 ms on Windows, 120 ms instead of 240 ms on Linux.

Memory

  • MFT quick scans peak far lower: building the tree takes about 57 bytes per item instead of 325. On 8.9 million items the backend now peaks at about 1.9 GB (on 8.6 million it used to reach 3.6 GB), and the administrator helper at 1.65 GB instead of 2.85 GB.
  • Saving a snapshot needs about 0.1 GB extra instead of 1.0–1.4 GB on 8.9 million items (formerly the highest point of the scan), in 0.8 s instead of 2.8 s. A snapshot saved while live monitoring changes the tree is no longer half before and half after a change, which could leave it unopenable. Snapshot files are unchanged.
  • Opening a snapshot needs half the memory: 0.95 GB instead of 1.8 GB for 8.7 million items.
  • No more memory spikes every few seconds while files change after a scan: the details panel's summary is worked out in small pieces, once for everyone asking, at most every 10 s on large scans. On 3.2 million items with files changing for a minute, the backend peaks at about 660 MB instead of 1.3 GB (about 300 MB with mapped files) and settles at 600 MB instead of 835 MB.
  • Long live monitoring no longer adds gigabytes at once: renumbering the tree after many changes needs about 1 GB extra on 8.7 million items instead of 6.3 GB.
  • On Linux the backend keeps about half as much after a scan, as glibc now hands freed memory back: about 170 MB instead of 310 MB after 700,000 items. Other C libraries, such as musl, are unchanged.
  • Closing a tab while its snapshot loads frees the memory at once, instead of keeping it until SpaceKnife quits (about 1.1 GB for 8.6 million items); a scan that starts after its tab closed no longer keeps running.
  • Less memory all the time: about 50 MB less, as the palette's pinyin search no longer loads a Chinese dictionary at start, and 8 bytes less per item in an open scan (about 66 MB on 8.6 million items); the treemap also redraws faster after a change.
  • A rescan of a known drive sets its memory aside once, from the last complete scan's item count, instead of growing and copying as it goes.
  • A hidden window gives memory back: minimized or covered, it releases its drawing surfaces; hovering the treemap reuses the same buffers.

Fewer writes to your drives

  • Windows hard scans keep folders' access times, so scanning a drive of 8.7 million items no longer writes 1.5–3.3 GB. Where that isn't allowed (read-only drives, system folders for a standard user, folders only Windows may change such as C:\Windows\WinSxS), folders open as before, so a whole system drive still sees about 0.25–0.7 GB.
  • On drives that keep no access times, Windows hard scans skip the slower way of opening folders (ReFS by default; NTFS with fsutil behavior set disablelastaccess at 1 or 3). After you turn access-time updates off and until Windows restarts, a hard scan of such a drive can still update them, as before 0.3.4.
  • Linux hard scans keep the access times of folders you own: under relatime, the first scan of a day used to rewrite the inode of every folder not opened that day. These folders are now opened that way directly, one system call fewer each; folders owned by others are listed as before.
  • Scans past the Scan data memory limit write half as much: their mapped files grow in place, without zero-filling on Windows or copying; about 0.67 GB instead of 1.3 GB for 3.2 million items.

Accuracy and safe deletes

  • WinBtrfs folders whose names differ only in case (a and A) are each counted with their own contents; one used to be counted twice and the other not at all (102 such pairs on the test drive). Deleting or trashing an item whose path would reach its twin is refused, and items no path leads to alone can't go into the delete basket. Folders with names Windows can't hold (a colon, say) still show as unreadable, now saying why.
  • Folders whose names end in a dot or a space are listed correctly without the native extension: odd. showed the contents of odd beside it, and deleting it after a hard scan deleted odd. Deleting, trashing or basketing such an item is now refused, and nothing is touched.
  • Very long paths no longer drop out on Linux and macOS: folders whose path is 4,096 bytes or longer (1,024 on macOS) are opened a piece at a time and counted, instead of shown as inaccessible.
  • A stopped and continued scan shows the time of both parts, without the pause, and keeps the first start time. It used to show only the second part (0.6 s for a 0.85 s scan, so the speed came out too high), and even a negative time while running. Switching a running scan to the MFT quick scan no longer shows a negative time either, and if that read fails, the hard scan's time carries on.
  • The details panel and the picture no longer fail now and then during a hard scan, and files in a folder with its own class (a game, a project) no longer get their extension's color by mistake.
  • The details panel no longer sits on Loading… when part of a summary fails (seen in 0.3.3 after a scan of / on Linux): it shows the rest with a note on what is missing, falls back to classes by extension, and offers Try again when the item itself can't be read. Each kind of failure is logged once per scan.
  • Folders you classify take their class as soon as a scan lists them, even when none of them was listed yet when the scan was first drawn.

Live monitoring

  • Linux no longer misses changes made right after a scan: once a folder's watch is on, its modification time is checked against the scan's and a changed folder is read again; polled folders get the same check, on macOS too.
  • A standard user's scan of / on Linux is watched in full: folders it can't read, such as /root, are left out instead of polled, so the status bar says Live monitoring, not partly polling. A folder that becomes readable is listed and watched after F5, and folders with paths of 4,096 bytes or more are now really polled. On macOS and Windows a change inside an unreadable folder no longer makes SpaceKnife open it (on macOS that asked for access to places like Desktop).
  • A long job on one scan no longer holds up the others: a file change used to wait behind it, and every picture, summary and new view behind that change, so a scan started meanwhile seemed stuck for minutes.
  • The block under the pointer stays lit while the view updates: its highlight, the light around its folders and the hover card (with the new numbers) stay through each redraw, as does a row lit from the results list; the comparison view's hover card no longer flickers.

Interface

  • Thin scroll bars everywhere: rounded, without arrows or track, wider under the pointer, in both themes, instead of Windows' wide gray bar.
  • The toolbar fits narrow windows: the filter box shrinks first, then the chips show only their swatch, and the coloring, the chips and finally the visualization switch move into a new More (…) menu, so every control stays in reach at any size, in a comparison too.
  • Dark theme touch-ups that came with the light one: dark scroll bars, drop-downs and check boxes; readable class icons, update badge text and the log's error level under the pointer; the selected treemap block is no longer darkened by its own shadow; a custom accent color now also reaches the compare view's New badge and the filter box; sizes on the lit bars of the flame graph and the polar flame graph are readable.
  • Settings › File classes: clicking the left end of a class name no longer opens the color picker.
  • The log panel lines up in English: the level and category columns fit their longest name, so Permissions no longer runs into the message and Warning stays inside its badge.

Known limitations

  • Nothing is code-signed or notarized yet (the macOS builds are ad-hoc signed); deb and rpm not yet tested on clean RHEL 9 / Ubuntu 22.04.
  • No seamless update yet for the macOS dmg, deb and rpm: the card opens the disk image or package. The macOS portable now has it.
  • The ARM portables were built and tested on GitHub's ARM runners only, not yet on ARM hardware; the installers are x64 only.
  • On WinBtrfs, a scan that starts at (or inside) one of two folders whose names differ only in case reaches the other one, as do Explorer and copied paths; scan the folder that holds both.

License: MIT. Third-party licenses ship in resources/licenses/.

简体中文

SpaceKnife 是看清磁盘被什么占满的硬盘占用分析工具，支持 Windows、Linux 和 macOS。它受 SpaceSniffer 启发，是独立开发的新项目，与 SpaceSniffer 及其作者没有任何关联。官网 · 文档

这是预发布版：Windows 和 Linux 版没有代码签名，macOS 版是 ad-hoc 签名，未经公证。

所有文件都由 GitHub Actions 构建并检查：run 40255561003。

下载

系统 文件 大小
Windows 10+ x64 SpaceKnife-0.3.4-Setup-x64.exe 137 MB
Windows 10+ x64 便携版 SpaceKnife-0.3.4-win-x64-portable.zip 175 MB
ARM 版 Windows 11 便携版（新） SpaceKnife-0.3.4-win-arm64-portable.zip 171 MB
macOS 14+，Apple Silicon SpaceKnife-0.3.4-mac-arm64.dmg 141 MB
macOS 14+，Intel SpaceKnife-0.3.4-mac-x64.dmg 148 MB
macOS 14+，Apple Silicon 便携版（新） SpaceKnife-0.3.4-mac-arm64-portable.zip 141 MB
macOS 14+，Intel 便携版（新） SpaceKnife-0.3.4-mac-x64-portable.zip 148 MB
Ubuntu 22.04+ / Debian 系 spaceknife_0.3.4_amd64.deb 132 MB
RHEL 9+ / Fedora 系 spaceknife-0.3.4.x86_64.rpm 119 MB
其他 Linux x64 SpaceKnife-0.3.4-x86_64.AppImage 164 MB
Linux x64 便携版 SpaceKnife-0.3.4-linux-x64-portable.tar.gz 162 MB
Linux arm64 便携版（新） SpaceKnife-0.3.4-linux-arm64-portable.tar.gz 160 MB
  • 从 0.3.3 升级：点右上角的徽章，卡片下载对应安装方式的文件并核对 SHA-256，然后可选「无缝更新」或经典方式。快照和设置都保留。
  • Windows：直接在旧版上运行新安装程序。未签名，SmartScreen 提示时点「更多信息 › 仍要运行」。
  • macOS：拖进「应用程序」；第一次打开到「系统设置 › 隐私与安全性」点「仍要打开」（步骤）。
  • Linux：deb / rpm 装到 /opt/SpaceKnife（命令 spaceknife）。AppImage 需要 FUSE 2（libfuse2），或加 --appimage-extract-and-run；可用 AppImageUpdate 就地更新（附带 .zsync 文件）。
  • 便携版：解压即用，数据都在程序旁的 data 里；手动升级时替换 data 以外的文件。
    • 新增 macOS 便携版：解压后打开 SpaceKnife.app，让它和 data 文件夹待在一起。还没经过公证，和 dmg 一样要在「系统设置 › 隐私与安全性」里放行一次。
    • 新增 ARM 便携版：ARM 版 Windows 11 和 Linux arm64；安装包仍只有 x64。ARM 版 Windows 上的 x64 便携版，会在 0.3.4 之后的第一次更新时换成 ARM 版；想现在就换，把它的 data 文件夹复制进解压好的 ARM 便携版。
  • 校验和：SHA256SUMS.txt（安装包）、SHA256SUMS-portable-*.txt（Windows 和 Linux 便携版）、SHA256SUMS-mac-*.txt（dmg 和便携版，每种芯片一份）。

新功能

  • 浅色主题：默认跟随系统的浅色 / 深色设置（「设置 › 外观 › 主题」：跟随系统、浅色、深色），树图、火焰图和火焰-极坐标图一起换色，立即生效、不闪白；无头模式下跟随浏览器。在「设置 › 文件类别」里选的类别颜色只作用于当前主题，勾选「同时应用到另一主题」则两套都用；这一版之前选的颜色两套主题都保留。
  • ARM 便携版：ARM 版 Windows 11 和 Linux arm64 也有便携版了，用法和 x64 的一样。安装包仍只有 x64。
  • macOS 便携版（Apple Silicon 和 Intel）：快照、设置都存在 SpaceKnife.app 旁边的 data 文件夹里，不写进「资源库」；macOS 从隐藏的副本运行应用（App 转移）时，它照样找得到这个文件夹。「无缝更新」和 Windows、Linux 便携版一样可用。
  • 「本机磁盘」记住每个卷最近一次完整扫描：文件类别、最大的文件夹、文件数和扫描时间，在离开这一页、关掉标签页、重新载入窗口或重启之后照样显示，直到下一次完整扫描。只有同一个卷（盘符或挂载点，加上卷序列号）才会拿回它们。
  • 「本机磁盘」顶部的「文件类别」条：把所有已知类别构成的卷加在一起，写出每类多大、占多少，以及算进了哪些卷。
  • 帮助页「三种可视化」（文档）：讲清树图、火焰图和火焰-极坐标图各自怎样组织画面，附一张对照表，每种配一张图。火焰-极坐标图可以看成多层堆叠、没有中心区域的饼图：每一环是一层文件夹，角度就是比例。
  • 新开关「大扫描存进映射文件」（「设置 › 高级 › 内存」，默认关）：约 200 万项以上的扫描把数据存进缓存文件夹里的内存映射文件，系统可以随时把它们移出内存。320 万项的盘，后端扫完稳定在约 250 MB（不开约 600 MB），扫描中峰值约 400 MB（不开约 750 MB），速度不变；代价是扫完后写一次文件，每项约 200 字节（860 万项约 1.8 GB）。
  • 命令行 scan --mft：像应用里的 MFT 快速扫描那样读取整个本地 NTFS 卷的 $MFT（Windows；请求一次管理员权限；默认不开）。只是一个文件夹、别的文件系统、网络盘、一次多个路径，或者拒绝了管理员授权时，先写一行原因，再逐个文件夹扫描；结果里写明这次是怎么读的。

修复

安全

  • 拒绝 eMudhra 出问题的证书：2026 年 10 月，印度的证书颁发机构 eMudhra 被发现有八张中间证书的私钥在 2025 年生成时出了错，能从公开的证书算出来；10 月 17 日到 20 日，Firefox、Chrome、Apple 和 Microsoft 先后拦截了这八张证书。SpaceKnife 现在带 Electron 44.9.3，会拒绝它们；检查更新（只连 GitHub）在 Windows 和 macOS 上改由系统验证证书，系统拦截的证书它也一并拒绝。SpaceKnife 的窗口只显示软件自带的页面，自己不连互联网，所以此前没有受影响。Linux 上请把 ca-certificates 保持为最新。

扫描更快

  • 硬扫描自己决定同时列几个文件夹：依据 SpaceKnife 能用的 CPU 数（现在算上 CPU 亲和与容器配额）和文件夹是否要从盘上读；磁盘负载上限照样有效。NVMe 上先清空缓存，191 万项的 NTFS 盘从 11.4 秒降到 7.7 秒，322 万项的 ReFS 盘从 35 秒降到 22 秒；都在内存里时，这块 NTFS 盘从 2.6 秒降到 2.1 秒，CPU 时间少 17%。
  • Windows 硬扫描从父文件夹打开子文件夹，不再每次从盘的根目录找下去（NTFS、ReFS、WinBtrfs；每个都按文件 ID 核对）。都在内存里时，321 万项的 ReFS 盘 5.2 → 3.8 秒，880 万项的 NTFS 系统盘 13.1 → 12.6 秒。
  • 建树改由原生代码完成，列目录不用等它：77 万项的 Linux 系统热缓存扫描 0.34 → 0.26 秒；从盘上读 767 万项的 C:\Users，15.8 → 14.9 秒。
  • 硬链接改由原生代码计数：60 万项的 Linux 系统（其中 16 万个是 uv 缓存和虚拟环境共享的硬链接），热缓存扫描 0.37 → 0.29 秒。
  • 稀疏、压缩文件不再拖慢 Windows 硬扫描：本地 NTFS、ReFS、WinBtrfs 盘上，占用改取列目录时文件系统给的计数，不再逐个打开这些文件去问（基准测试的冷缓存扫描里占了 12.8 秒）。存在 NTFS 文件记录里的小文件（约 513–700 字节）和 ReFS 上内联存放的小文件（约 1.5 KB 以下）占用记 0，不再按一簇算，和 MFT 快速扫描一致。
  • MFT 快速扫描快了约四倍：890 万项约 4.7 秒，以前约 19 秒（读取 7.2 → 2.8 秒，建树 12 → 0.4 秒）。同时读几块按盘的速度边读边定，SATA 固态盘不会被一长串读堵住，NVMe 盘多读几块；负载上限照样有效。结果逐项不变。
  • 命令行扫描启动和结束都更快：扫一个空文件夹，Windows 上 220 毫秒（以前 410），Linux 上 120 毫秒（以前 240）。

内存

  • MFT 快速扫描的内存峰值大降：建树每项约 57 字节，以前约 325 字节。890 万项的盘，后端峰值现在约 1.9 GB（以前 860 万项就冲到约 3.6 GB），读 $MFT 的管理员助手约 1.65 GB（以前约 2.85 GB）。
  • 保存快照：890 万项的盘只多占约 0.1 GB，以前多 1.0–1.4 GB（是整次扫描的最高点），耗时从 2.8 秒降到 0.8 秒。实时监控正在改动树时保存的快照，不会再一半是改动前、一半是改动后（以前可能因此打不开）。快照文件格式不变。
  • 打开快照只要一半内存：870 万项从 1.8 GB 降到 0.95 GB。
  • 扫完后文件持续变化，内存不再每隔几秒冒高：详情面板的汇总分小块计算，同一份只算一次，大扫描时最多每 10 秒刷新一次。320 万项的盘、文件连续变化一分钟：后端峰值从约 1.3 GB 降到约 660 MB（开着「大扫描存进映射文件」约 300 MB），之后稳定在约 600 MB（以前 835 MB）。
  • 实时监控开久了，内存不再一下子多出好几 GB：改动多了之后给整棵树重新编号，870 万项的盘只多约 1 GB，以前多约 6.3 GB。
  • Linux 上扫完后后端占的内存少一半左右：现在让 glibc 把释放的内存还给系统，扫完约 70 万项后稳定在约 170 MB，以前约 310 MB。musl 等其他 C 库不受影响。
  • 快照加载途中关掉标签，内存立即释放，不再一直留到退出 SpaceKnife（860 万项的快照约 1.1 GB）；标签关掉后才开始的扫描也不再继续跑。
  • 平时占的内存更少：命令面板的拼音搜索不再在启动时载入中文词典，少约 50 MB；打开的扫描每项少 8 字节（860 万项约 66 MB），树图在文件变化后重画也更快。
  • 重新扫描扫过的盘时，一次留好内存：按上次完整扫描的项数分配，不再边扫边扩容、整份复制。
  • 窗口隐藏时归还内存：最小化或被完全挡住时交还绘图画布；鼠标在树图上移动时复用同一块缓冲。

减少写盘

  • Windows 硬扫描保留文件夹的访问时间：扫一次 870 万项的盘不再写 1.5–3.3 GB。不允许这样打开的地方照旧（只读的盘、标准用户进系统文件夹、C:\Windows\WinSxS 这类只有 Windows 自己能改的文件夹），所以扫整个系统盘仍会写约 0.25–0.7 GB。
  • 在本来就不记访问时间的盘上，Windows 硬扫描不再用更慢的方式打开文件夹（ReFS 默认如此；NTFS 在 fsutil behavior set disablelastaccess 为 1 或 3 时）。关掉访问时间更新后、Windows 重启之前，硬扫描这些盘仍可能像 0.3.4 之前那样更新访问时间。
  • Linux 硬扫描保留你自己的文件夹的访问时间：在常见默认的 relatime 下，一天里第一次扫描会改写所有一天没打开过的文件夹的 inode。现在打开时就让访问时间保持不变，每个文件夹还少一次系统调用；别人的文件夹照旧。
  • 超过「扫描数据内存上限」的扫描写盘量减半：映射文件原地变大，不再先写满零（Windows）或每次复制到新文件；320 万项约 0.67 GB，以前约 1.3 GB。

结果准确，删除稳妥

  • WinBtrfs 盘上只差大小写的文件夹（a 和 A）各按自己的内容计算；以前一个算两遍、另一个一项都没算（测试的盘上有 102 对）。删除或移到回收站时，按路径会打开另一项的一律拒绝；没有路径单独指向的项不能加入删除篮。名字里有冒号等 Windows 名字不能有的字符的文件夹仍显示为无法读取，但会写明真正的原因。
  • 没有原生扩展时，名字以点或空格结尾的文件夹也能正确列出：以前 odd. 列出的是旁边 odd 的内容，硬扫描之后删除 odd. 删掉的是 odd。现在删除、移到回收站或加入删除篮这样的项都会被拒绝，什么都不动。
  • Linux 和 macOS 不再漏掉路径很长的文件夹：路径达到 4,096 字节（macOS 上 1,024 字节）的文件夹改为逐段打开、照常计算，不再显示成无法访问。
  • 停止后继续的扫描，耗时算上两段（不含中间停着的时间），开始时间保持第一次的。以前只算第二段（0.85 秒的扫描显示 0.6 秒，速度也算高了），扫描期间甚至是负的。中途改用 MFT 快速扫描时耗时也不再是负的；MFT 读取失败、接着硬扫描时，耗时接着原来的算。
  • 硬扫描进行中，详情面板和画面不再偶尔出错；所在文件夹有类别（游戏、项目）的文件，不再误按扩展名配色。
  • 汇总有一部分算不出来时，详情面板不再一直「正在读取…」（0.3.3 在 Linux 上扫 / 后碰到过）：其余内容照常显示并写明缺了什么，文件夹类别算不出就按扩展名统计，连这一项本身都读不出时给出「重试」。同一种失败每次扫描只记一条日志。
  • 自己归类的文件夹，扫描一列到就按所选类别算，即使扫描第一次画出来时它们一个都还没列到。

实时监控

  • Linux 上不再漏掉扫描刚结束时的改动：文件夹一加上监视，就拿它的修改时间和扫描记下的比一次，变了就重新读；轮询的文件夹也这样核对，macOS 上也是。
  • Linux 上普通用户扫 / 不再「部分轮询」：扫描读不到的文件夹（如 /root）不再拿去轮询，状态栏显示「实时监控中」。以后变得能读的文件夹，按 F5 就会列出并开始监视；路径达到 4,096 字节以上的文件夹现在真的能轮询到。在 macOS 和 Windows 上，这种文件夹里的改动不再让 SpaceKnife 去打开它（macOS 上那会弹出访问桌面等位置的授权）。
  • 一个扫描上的长任务不再拖住其他扫描：以前文件变化排在它后面，所有画面、汇总和新视图又排在这次变化后面，这时开始的扫描看起来卡住好几分钟。
  • 视图更新时，鼠标下的块一直亮着：高亮、外层文件夹的光晕和悬停卡（数字跟着更新）在每次重画时都保持，从结果列表点亮的行也一样；对比视图的悬停卡不再闪。

界面

  • 所有滚动条都变细了：圆角，没有箭头和轨道，指针移上去时变宽，两套主题都一样，不再是 Windows 默认的宽灰条。
  • 窄窗口下工具栏不再被截断：先压缩过滤框，再把芯片缩成色块，然后依次把配色、芯片、最后是可视化切换收进新的「更多」（…）菜单，任何窗口大小下每个控件都点得到，快照对比时也一样。
  • 随浅色主题而来的深色小改动：滚动条、下拉框和复选框也是深色；类别色块上的图标、更新徽章的文字和日志里鼠标所在行的错误级别都看得清了；树图里选中的块不再被自己的投影压暗；自定义的强调色也用到对比视图的「新增」角标和过滤框上；火焰图和火焰-极坐标图点亮的条上，大小看得清了。
  • 「设置 › 文件类别」：点类别名称的左端不会再弹出取色器。
  • 英文界面下日志面板对齐了：级别和分类两列按最长的名字定宽，「Permissions」不再压住后面的消息，「Warning」不再超出底色块。

已知限制

  • 都还没有代码签名或公证（macOS 版是 ad-hoc 签名）；deb、rpm 还没在干净的 RHEL 9 / Ubuntu 22.04 上测过。
  • macOS 的 dmg 和 deb / rpm 仍没有「无缝更新」：卡片会打开磁盘映像或安装包。macOS 便携版现在已经支持。
  • ARM 便携版只在 GitHub 的 ARM 运行器上构建和测试过，还没在 ARM 真机上试过；安装包只有 x64。
  • WinBtrfs 盘上两个只差大小写的文件夹，从其中一个（或它里面的文件夹）开始扫描，到达的是另一个，资源管理器和复制出去的路径也一样；请扫描包含两者的文件夹。

许可证：MIT。第三方许可证在 resources/licenses/ 里。

Assets 22
Loading