>目标是：前几次出现存储空间不足时，快速进行文件整理，腾出空间

那你问的是 X/Y 问题。存储空间不足时应该运行 cleanmgr.exe 清理空间，或者使用（ Windows 10 开始时髦的） Storage Sense 自动整理。

搜索了一下 SpaceSniffer 、WizTree 的资料，没有看到它们如何处理硬链接（同一个文件多个文件名）。

>解释每个文件夹的创建应用（如果是应用创建的话）

这个问题无解，因为文件系统并不会记住每个文件夹是哪个程序建立的。当然，根据典型路径、名称做些提示是可以的。

@geelaw #41 ……是说觉得 AI 写得好的人，服了回复按钮和虚拟键盘的位置关系了 🤣 另外这件事情和文章水平无关，洗稿的人把文章改得再好，也应该追究。

@yufeng0681 #38 属于不知道好赖的：

建议挪到“分享创造”。

我的方法是：需要赋予域名的对象本来就有名字。

@geelaw #9 重新尝试发现可以列出目录结构，但是不能下载文件，最后一次已知的可下载时间是 2024-01-09 ，同时注意到上面写着 powered by alist ，不知道这个变化是 alist 引起的还是站主的选择。既然如此，推荐 GitHub 上存档的版本。

@elvis923 #7 感到困惑，因为我直接访问就可以看到，不需要登录。（ IP 是美国家用宽带或者美国的数据网络。）

@ala2008 #8 很有趣的推理。

远程电脑不知道另一台电脑对移走的数据会做什么，实际上跨磁盘移动就是复制并删除原本，因此远程电脑的不可能选择性允许或禁止移动、删除。此外，这不是安全问题，所以权限模型不会建模之，因此不能用权限解决。

SMB 哪个系统都可以有，但并不是所有系统都有标准化的回收站功能，而且远程删除的文件也不一定能很好判断该放入哪个用户的回收站，因此 SMB 不太可能支持把远程文件移动到回收站。

现成的解决方案有 OneDrive：本地删除导致云端移动到回收站；本地删除时若文件已经下载到本地，则本地回收站也有一份；每台电脑可以选择使不同的文件离线可用。

或者自己写一个 SMB 访问程序，且不提供删除的 UI 。

>解决 Windows 系统中应用程序与系统组件更新割裂的问题

似乎是不存在的问题，主流操作系统里系统软件和应用软件的更新，一直都是分开的。当然，可以说这是一种新的尝试，但把一切都归结于一种缺点，属于是无厘头的 marketing 手段了。

有些 lnk/exe 无法固定，是因为 manifest 等原因，例如 rundll32.exe 的 manifest 要求自己不被固定到任务栏和“开始”，但 rundll32.exe 的快捷方式无此限制。

@Hayashikawa #1 和快捷方式的位置无关，Windows 的使用没有那么复杂。

如果要固定 exe 文件（应用程序）或者 lnk 文件（快捷方式），打开此文件的上下文菜单（“右键”），然后点 Pin to Start 就可以了。对于快捷方式来说，我记得至少从 Windows 8 开始就是这样了。

不过我刚才试了一下，24H2 上必须从 explorer.exe 里打开上下文菜单 Pin to Start 才会生效，在其他进程里（例如 Notepad 的“打开”对话框）虽然也有 Pin to Start ，但点击不会有任何作用。应该是和 Pin to taskbar 有相同的检测，但是枚举菜单项的时候忘了在非 explorer.exe 里不显示。

AES-NI 只是把 AES 中的一部分做成了指令，作用一次 AES PRP 需要调用指令多次，每个指令的参数也是定长的。特别地，并不是一个指令就可以加密任意长的字节数组。

类似的思路运用到 FFT 上，首先需要找出 FFT 中反复用到的同类、定长参数的步骤，然后做成指令，一通分析之后可能会发现没有很好的除了加法、乘法、求余数之外的很好的抽象层。

我在 #86 的主要观点有两个：

1. 如果你希望用一个工具自动检查文件复制的情况，应该问“有什么工具能追踪 Git 历史中复制的文件”，而不是“Git 基操：怎么样复制一个文件，能保持历史记录”，因为后者的自然解读是“保持 Git 所认为的历史记录”，即 git blame 的结果。
2. 如果你希望确保 git blame 总是得到你希望的历史（这和其他第三方工具没有任何关系），那么单纯复制 + git add + git commit 是不行的。

@xiangyuecn #87 您似乎没有理解“TortoiseGit 不是 Git”这句话。

你可以自己试试，在 Git 2.42 上

git init
>a.txt echo 1
git add a.txt
git commit -m first
>>a.txt echo 2
git commit -am second
cp a.txt b.txt
git add b.txt
git commit -m copy
git blame b.txt

你会看到 b.txt 的每一行都是 copy 导致的，而不是 first, second 导致的。

现在，为什么 TortoiseGit 会显示 b.txt 来自 a.txt （按照你的说法是这样的，我自己不用 TortoiseGit 所以不知道）。答案是因为 TortoiseGit 会自己读取 Git 的 commit 对象并自己追踪文件，和 git blame 没有任何关系。

Git 不会认为 b.txt 和 a.txt 有相同的历史，至于 TortoiseGit 有自己的解读方式，那是 TortoiseGit 的事情。本质上来说，你自己写一个追踪复制的程序，等价于你用 TortoiseGit ，都和 Git 自带的 blame 解读没有任何关系。

@xiangyuecn #78 我不确定为什么你认为 TortoiseGit 能识别 = 这是一个 Git 的基本操作。TortoiseGit 并不是 Git 。如果你期待的是存在一个基于 Git 的工具可以识别，提问的时候应该说清楚，你的答案是 TortoiseGit 的基本操作，而非 Git 的基本操作。

使用 merge 反复重命名的方法可以确保 Git 本身可以识别，这一点在你需要远程查看 git blame 的时候十分重要——毕竟没法要求 GitHub 远程帮你运行 TortoiseGit 。