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

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 。

@dfkjgklfdjg #30 git mv 和删除文件再新建没有任何区别。你在 #38 也说了，Git 是猜的，但

>但是如果猜到了，那么提交历史里面是会有标注是 rename

这是错误的，commits 里不会标注为 rename ，只有计算 diff/blame 的时候 Git 才会去（根据 commits 的内容）识别重命名关系。

@xiangyuecn #37 git cp 很难成立，原因：git mv 和 git rm 都不产生 commit ，而是修改 index 等，因此基于一致性，git cp 也应该不产生 commit 而只是修改 index ；但是 git 数据库里面每个 commit 存的是状态，而不是“怎么来的”，因此要让 git blame 认识到一个文件是另一个的副本，要么 git blame 自动检测（见下一段），要么这个信息必须存在于 commits 的历史中，用多分支的做法就是把这个信息存放在历史中，这必然要创建多个 commits ，因此 git cp 不会这样做。

目前的实现里，如果一个 commit 的惟一变化是有一个新文件 B ，并且新文件 B 和某个已经存在的文件 A 内容一样，那么 Git 会认为新文件是“手工重新写出来的”，不会认为 B 来自于 A 。我觉得这样设计的原因是很多配置文件可能确实会是内容上一样的，但更可能是基于不同的原因分别写出来的，所以不宜合并历史。

git mv 也并不保证 git blame 会认为移动前后的文件有关联性，这种信息依然是 Git 通过对比两个 commits 算出来的。

@magggia #9
@mercury233 #10
@mangoDB #19
见 #22

@xubingok #17 这当然不是造假，考虑各种变种需求：文件拆分成两个，希望各自保留历史；两个文件合并，希望保留各自的历史。

@Trim21 #21 模糊识别重命名确实有这个问题，但是 Git 的原理保证：如果一个 commit 里面只发生不同内容文件的重命名（没有内容修改、没有多个同内容文件重命名），那么历史可以正确用 blame 追溯。（不满足此条件则会有模糊匹配的问题，所以我给文件改名的时候都是一个 commit 只做改名一件事的。）

https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904

基本原理是：

- blame 在 merge commit 处会追踪文件来自各个 parents 的部份。
- 让文件 a 和 b 来自 merge 的两个 parents 。
- 让文件 a 来自更早的 a 。
- 仍文件 b 来自更早的 a 。

我的做法和 Raymond Chen 不一样，假设当前在 branch "current":

1. 重命名当前文件

git checkout -b copy
git mv a _
git commit -m 'Prepare to copy file.'

2. 把当前文件在第一个分支上恢复为原来的名字

git checkout -b copy1
git mv _ a
git commit -m 'Restore name of file.'

3. 把当前文件在另一个分支上重命名为副本的名字

git checkout -b copy2 copy
git mv _ b
git commit -m 'Copy file.'

4. 合并两个修改

git checkout copy
git merge --no-ff -m 'Finish copying file.' copy1 copy2

5. 回归原分支

git checkout current
git merge --no-ff -m 'Copy `a` to `b`.' copy

6. 删除中间分支

git branch -d copy copy1 copy2

@Fffys #7

>但是我没有证据证明我更早就开始了？
通常不需要证据，采用“问心无愧”制。

>预印本因为目前系统设计还没有实现，担心写得不详细反而给别人启发
大多数情况这属于多虑。

#8
>套瓷
我没有经验，但我觉得你需要教授帮助的时候，隐藏信息只会阻碍效率。

@Fffys #4

>25 年的会议，截稿是去年，发表是今年，不知道这种情况应该算今年的会议还是去年的会议？

当然是“今年的”，哪一年会议发生，就是哪一年（除非每年都开会，中间某一年因为一些原因推迟或提前，那么应该依然用原定的年份序号）。

@Fffys #2

>现在距离去年已经有 5 个月了。

是为了表达困惑，因为通常来说会议纪要 (proceedings) 是伴随会议发生出版的。去年的会议是否有回放录像？有的话，什么时候公布的？对方论文是否已经有过预印本？如果撞车工作是一个月之前首次广泛公开，那么我觉得可以 claim 是 independent, concurrent work.

如果你认为撞车很严重，那可能投另一个 venue 比较好，当然如果你希望还能出版，最要紧的任务是写出来、放在预印服务器上，给自己的工作加上日期。

>毕业论文，chatgpt 说可以毕设和这个投稿用同一个，不知道是否可以？

这个问题你应该问学校和投稿的 venue 。

>发现有一篇综述和我在做的完全同一个方向甚至最后提出的想法、技术栈完全一样

我觉得第一件事是，静下心来思考对方是不是真的和自己一样。很多时候会被被 scoop 的冲击冲昏头脑，我自己就这样过好几次，但实际上重新思考表明，感觉 scoop 自己的工作和自己的工作实际上更多是互补而非重合的关系。

>不能一稿多投

楼主目前没有面临这个问题，对于这个问题我觉得最简单的答案是：不能一稿多投，已经被出版的不能直接重投另一个地方（除非两个 venues 事先同意了这一点）。此外，只要自己觉得别扭的操作，也都不要做，就可以了。

>去年同一个会议接收的论文
>这个论文发表还不到一个月，看完之后总觉得有种成果被抢走一半的感觉

现在距离去年已经有 5 个月了。

>技术栈完全一样
>我是实践这个论文是理论

为什么理论论文会提出具体的技术栈？感觉很神奇。

————

>这种情况下还有机会中稿吗？

如果楼主当下没有其他要紧的活儿，那么这是错误的问题。即使不能被接受，你可能也想把文章写出来，并给它一个日期，至少你可以 claim 是独立工作（取决于对方文章第一次公开的时间，也可能是 concurrent ）。

当然，楼主的文章必然是要 cite 已经发表的这篇的。结合前面的建议（思考是否是互补而非重合），写对比相关工作的时候，更容易想清楚如何凸显自己文章的新颖之处。

@datou #50 好像说明不了啥，因为 HTML 5 惟一合规的编码是 UTF-8 。

@ysc3839 #44
https://learn.microsoft.com/en-us/windows/win32/api/windns/ 后缀是 _UTF8
https://learn.microsoft.com/en-us/windows/win32/api/webservices/ 后缀是 Utf8

@mikewang #36 我印象里见过 -U8 结尾的 Win32 API ，用这个比设置代码页为 65001 之后用 -A 要好，当然，-U8 和 -A 在面对目前的文件系统时，都不如 -W 好。

-A 属于为了兼容性维持的 API ，内部操作都是转换为 UTF-16 之后调用 -W 的；我的理解是允许 manifest 设置 65001 是为了让 POSIX 程序最初的移植容易一点，而非作为主要存在的形式。

因为文件系统的路径并不需要是合法的 UTF-16 ，所以直接用 -W 和文件系统交互依然是惟一正确的选择。