看到Linux 7.1主线合并新NTFS驱动笑死我了，以前用Paragon那套，写个大文件跟开老解放爬长坡似的，顿挫感拉满哈哈哈。在非洲援建那两年，工地Win本跟Linux终端混用，日志盘动不动就乱码，修数据比修变速箱还费头发。现在内核原生接手，底层协议卷起来对咱们绝对是好事，毕竟竞争才能出真活儿嘛。不过新驱动对长路径和权限映射的兼容性咋样，我那些文艺复兴风格的矢量工程文件可经不起第二次折腾了，赶紧编译个内核试试水…

看到你提到“内核原生接手NTFS”，这里其实有个细节值得厘清：Linux 7.1 合并的并非全新从零开发的驱动，而是将 Paragon 提交的 NTFS3 驱动正式纳入主线——这和“原生”在技术语境中的通常含义（如 ext4、XFS 那样由社区长期维护的文件系统）仍有区别。NTFS3 虽由 Paragon 开发，但其开源版本自 5.15 起就已可选，7.1 只是将其状态从 staging 升级为正式支持模块，稳定性与维护优先级确实提升，但底层逻辑仍承袭商业代码库。

你在非洲工地遇到的日志乱码问题，我猜大概率不是驱动读写错误，而是字符编码映射冲突。NTFS 本身用 UTF-16 存储文件名，而 Linux 默认以 UTF-8 解析，中间若经由 ntfs-3g 或旧版内核驱动处理，对组合字符（比如带重音符号的法语地名）或长路径中的特殊符号容易出现截断或替换。新驱动改进了 unicode normalization 处理，但对 Windows ACL 权限到 POSIX 的映射仍较粗粒度——比如你那些“文艺复兴风格的矢量工程文件”若依赖 NTFS 的继承权限或加密属性，Linux 下可能直接忽略，导致后续回写 Windows 时元数据丢失。嗯

我自己去年在调试一个跨平台 GIS 数据集同步脚本时就踩过坑：同一份 .shp 文件在 Linux 写入后，Windows 端 ArcGIS 报“权限异常”，查了半天才发现是 NTFS3 默认未启用 uid/gid 映射，所有文件归属 root，而 Windows 把非用户属主的文件视为“来自网络”，自动加了只读属性。后来在 mount 时显式加上 uid=1000,gid=1000,umask=022 才稳住。

另外提一句，长路径支持虽有改善，但 Linux VFS 层对 PATH_MAX 的硬限制（通常是 4096 字节）仍是瓶颈。如果你的工程目录嵌套极深（比如 auto-generated 的 CAD 分层结构），即便 NTFS3 能处理，上层应用如 tar 或 rsync 仍可能报错。建议测试时用 getconf PATH_MAX / 确认当前系统上限，必要时改用基于 inode 的工具如 find -inum 绕过路径解析。

你编译内核前不妨先装个 7.1-rc 版本的 live ISO 试挂载——毕竟工地环境经不起反复 reboot。对了，日志盘若还在用机械盘，记得加 big_writes 和 noatime 挂载选项，能显著减少小文件写入延迟，比当年修变速箱省头发多了（笑）。

刚在工地用Linux挂NTFS盘拷贝CAD图纸那会儿，我也被权限映射坑惨过——不是乱码，是明明文件能读，一保存就变成root所有，Windows那边直接打不开。后来发现NTFS3默认把uid/gid硬编码成0:0，除非你挂载时显式指定uid=1000,gid=1000,umask=022，否则写入的文件在Windows里就是“受保护的操作系统文件”状态。

长路径的问题倒没那么玄乎。NTFS本身支持32k路径，但Linux VFS层有个PATH_MAX=4096的限制（其实是glibc的锅），所以超过4k的路径在用户态工具里会报错，但内核驱动其实能处理。你那些嵌套几十层的矢量工程文件夹，只要别用cp/mv这种依赖glibc路径解析的命令，改用rsync -r --files-from或者自己写个node.js脚本用fs.promises.readdir递归，根本不会触发截断。

顺便提一嘴：新驱动虽然进了主线，但压缩和加密流（ADS）还是只读。如果你的工程文件用了NTFS的透明压缩（比如某些旧版SolidWorks默认开），写入时会自动解压，体积暴涨不说，还可能触发磁盘空间误判。建议先用ntfsinfo -m /dev/sdXn看看卷是否启用压缩，有就提前关掉。

对了，编译内核前记得开CONFIG_NTFS3_FS_POSIX_ACL，不然ACL全丢。这选项藏得深，默认还不开……

dr__jp你提到Paragon的NTFS3其实早从5.15就进了可选模块，这让我想起去年帮一个在柏林做数字档案修复的朋友折腾老项目盘——她非说新驱动“背叛了开源精神”，结果扒了半天发现Paragon当初提交代码时留了个彩蛋：驱动里硬编码了他们公司域名的SHA1校验头，虽然不影响功能，但每次dmesg都能扫到一行可疑日志。我去后来社区有人提issue，他们才在6.x悄悄删了……话说你现在还跑GIS同步脚本吗？那套.shp权限坑是不是得配合setfacl才能保全Windows那边的ACL继承链~

刚从露营回来，帐篷里用树莓派跑了个内核编译测试NTFS3，顺手答一嘴。

你提到“文艺复兴风格的矢量工程文件”，我猜是那种嵌套十几层、带中文路径+空格+emoji命名的AI/SVG？这类文件在跨系统迁移时，真正的雷不是驱动本身，而是元数据语义断裂——Windows把NTFS的$EA（扩展属性）和ADS（Alternate Data Streams）当空气，Linux默认也不处理，但某些设计软件（比如旧版CorelDRAW）会偷偷往ADS里塞图层预览或版权水印。Paragon驱动早期版本直接忽略这些流，导致文件“看起来完整”实则丢了关键元信息，打开就报错。NTFS3主线化后，至少ntfs3.listxattr()能枚举出user.ntfs.streams.*了，虽然还不支持写入，但至少能detect到异常。

另外，权限映射的问题，crypto说得对，但有个更隐蔽的坑：时间戳精度错位。NTFS用100ns粒度，Linux VFS传统上只传秒级（后来加了纳秒但很多工具链没跟上）。你用rsync同步工程目录时，如果源是NTFS盘，目标ext4，哪怕内容一字未改，make也会因为mtime差了几微秒而全量重编——这在嵌入式交叉编译场景下特别致命。解决方案是挂载时加time_gran=100ns（需5.18+），或者干脆用--checksum绕过时间判断。

至于长路径，其实比glibc限制更麻烦的是shell glob expansion。你写个cp /mnt/ntfs/project/**/*.svg ./out/，bash在展开前就截断了，根本到不了系统调用层。建议用find -print0 | xargs -0管道处理，或者直接上Python的os.walk()——它走的是getdents64()，不受PATH_MAX约束。

最后提一嘴实战经验：我在温哥华帮人修过一台双系统工作站，问题出在休眠状态残留。Windows Fast Startup开着的时候，NTFS卷其实是“伪卸载”，Linux强行挂读写会触发journal回滚，看似成功，实则把最近两小时的CAD修改全干掉了。现在我的标准操作是：进Linux前先在Windows里跑powercfg /h off，或者挂载时加ro,prealloc先验数据完整性。

你那些工程文件要是真金贵，建议先用ntfsclone --save-image打个块级快照，比tar靠谱多了。毕竟NTFS3再稳，也架不住Windows自己半夜自动chkdsk……