/tag/迁移

前言 目前我把游戏分别放在本地 D:\game 和NAS的 G:\game （映射盘符）上运行(主要是gal和一些SLG太占空间了,又不想删)。长时间后, Local,Roaming,LocalLow 里会有各种游戏生成的存档和配置文件目录。 删游戏时这些目录并不会自动消失，AppData 越来越臃肿，想手动清理又怕删错，备份更是无从下手 于是我写了一套 PowerShell 脚本： 实时监控文件夹创建，自动记录游戏路径和存档位置，并在确认后将存档迁移到统一目录，在原位置留下符号链接 。这样既能把存档集中管理，又能让 AppData 保持干净。不过，NAS 映射盘符是整个过程里最大的坑（但大多佬们似乎用不到）。本文将分享我从“映射失败”到“稳定挂载”的全过程，以及脚本在中文转码、路径匹配、去重、队列管理等方面踩过的坑和最终方案。 而且我现在的环境很特殊：NAS 和主机用网线直连，主机通过 ICS 让 NAS 共享校园网。下一篇博客会补充 NAS 实战中的更多内容(为此我花了一周在学习网络通信协议)。 手动查找并迁移已有文件 1. 按修改时间查找文件 如果知道文件大概的修改时间范围，可以用以下命令快速定位： Get-ChildItem -Path "D:\game" -Recurse -File | Where-Object { $_.LastWriteTime -ge "2026-06-01 10:40" -and $_.LastWriteTime -le "2026-06-01 11:00" } 找到后根据完整路径判断属于哪个游戏，然后手动复制存档到备份目录（例如 D:\GameSaves\manual ）。 2. 批量迁移脚本（BAT 示例） 对于大量已知映射关系的配置文件，可以写一个批处理脚本。 注意：BAT 脚本如需输出中文，必须保存为 ANSI(GBK) 编码；而给 AI 或代码库看的脚本建议用 UTF-8。 @echo off set SRC1=C:\Users\admin\AppData\Local\GameA\Save set DST1=D:\GameSaves\GameA xcopy "%SRC1%" "%DST1%" /E /I /Y set SRC2=C:\Users\admin\AppData\LocalLow\GameB set DST2=D:\GameSaves\GameB xcopy "%SRC2%" "%DST2%" /E /I /Y echo 迁移完成 pause NAS 盘符映射 1. 在 Windows 中映射 NAS 文件夹 我的 NAS 型号是绿联 Dxp4800plus，通过 ICS 共享网络，设置的私网IP 为 192.168.137.20 。我把所有游戏放在 NAS 共享文件夹 ACG （原名 acg资源 ，后来改名）下，并映射到主机的 G: 盘。 正确映射方法（一定要勾选“登录时重新连接”） ： 右键“此电脑” → “映射网络驱动器”。 驱动器选择 G: ,文件夹选择 NAS设备\ACG 必须勾选"登录时重新连接" ，不然后面开机自启会出问题。 用校园网连接NAS时，在 网络 可能会找不到设备，需要先进入 WLAN 把校园网从专用切换为公用，再在 网络 里重新转为专用，才能发现 NAS 设备。我现在也没搞清楚根本原因是什么，如果佬们知道正确的修改方法请告诉我。 2. 几个踩坑点 踩坑 1：修改共享名称后映射失效 当我把共享文件夹从 acg资源 改名为 ACG 后，就无法进入之前映射好的 G: 盘了。这是因为映射驱动器指向的远程路径是 \\...\acg资源 ，而实际共享已不存在。 解决方法 ： 先删除旧映射G盘 按照上述步骤重新映射到新文件夹 ACG 一旦修改 NAS 共享名，必须同时更新所有客户端的映射，并更新脚本中的路径 踩坑 2：到底该用盘符（G:）还是 UNC 路径（\IP\share）? 这是困扰我最久的问题(主要是不停打开游戏和脚本测试,还要不断删除对应的文件和json内容)。 脚本需要匹配运行中游戏的可执行文件路径，而 Get-Process 返回的 Path 属性 在不同启动方式下表现不一致 ： 如果通过资源管理器双击 G:\game\xxx.exe 启动，进程路径有时是 G:\game\... （盘符形式）。 如果通过 \\192.168.137.20\ACG\game\xxx.exe 直接启动，进程路径是 UNC。 有些游戏启动器可能会强制转换路径。 我最初按 UNC 路径 \\192.168.137.20\ACG\game 设置 $gameRoot ，但实际运行时却匹配不到（因为进程路径是 G:\game 开头）。后来改为 G:\game 就成功了,所以最稳妥的做法是 把盘符和UNC都配置上 ，让脚本自己去匹配。 不知道为什么，在 powershell 中 cd \\192.168.137.20\ACG\game 却没有问题 踩坑 3：开机自启时 G 盘还未连上 设置任务计划程序开机启动脚本后，发现脚本虽然运行了，但始终检测不到 NAS 上的游戏。日志显示 [注意] 未检测到游戏进程 。 原因：用户登录后，系统需要几秒钟来恢复网络驱动器。而脚本在登录瞬间就执行了，此时 G: 盘还不存在。 解决方案 ：在任务计划程序的触发器设置中，添加 “延迟任务时间 30 秒” （或更长，如 60 秒），这样脚本会等待网络和映射完全准备好再启动。 实现自动化监控脚本 核心需求： 监控三个存档常用目录： %LOCALAPPDATA% 、 %APPDATA% 、 %USERPROFILE%\AppData\LocalLow （即 Local,Roaming,LocalLow ） 当有新文件夹被创建（某个游戏第一次生成存档）时，自动记录 同时检查本地 D:\game 和 NAS 映射的 G:\game 路径，检测当前运行的游戏进程并将其 exe 路径以 Base64 存入队列 1. 设置 PowerShell 执行策略 首次运行脚本前，需要允许执行本地脚本： Set-ExecutionPolicy RemoteSigned -Scope CurrentUser 2. 监控脚本（Watch-GameSaves.ps1） 以下为脚本核心结构（完整代码略去，仅说明逻辑）： 定义监控根目录、排除文件夹列表。 使用 FileSystemWatcher 监视 $watchPaths 下的文件夹创建事件。 事件触发后： 跳过已存在的连接点或排除文件夹。 延迟 3 秒，给游戏时间完成写入。 获取正在运行的进程，匹配路径是否以 D:\game 或 G:\game 开头。 将匹配到的第一个游戏 exe 路径转为 Base64（避免 JSON 中的转义和乱码问题）。 将存档路径、游戏 exe Base64、时间等信息写入 pending.json 。 3. 解决中文乱码：Base64 转码 因为游戏路径中可能出现中文（如“除灵猎人”），直接存储到 JSON 会导致编码混乱（而且很难解决，不论将文件保存为UTF-8还是GBK都不行，因为本质是在action中进行的解码）。解决方法是将 exe 路径进行 Base64 编码： { "srcPath": "C:\\Users\\admin\\AppData\\Local\\NebelTR", "time": "2026-06-04 15:28:26", "gameExeBase64": "RDpcZ2FtZVxSUEdcQkJR5aSn5aW944GNXOmZpOeBteeMjuS6ulzpmaTngbXnjI7kurotQ04tMS4xMlxHYW1lLmV4ZQ==", "dirName": "NebelTR", "remark": "" } 使用时通过 [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($base64)) 解码即可得到原始中文路径。 4. 避免重复记录已处理目录 某个存档目录已经成功迁移并创建了符号链接后，之后游戏再次运行，监控脚本又检测到同一目录的“创建”事件，就会导致重复记录。 解决方法 ：在向 pending.json 追加新条目之前，先检查队列中是否已存在相同的 srcPath 。若有，直接跳过，不重复添加。这样即使链接目录被误触创建事件，也不会污染队列，同时也避免了后续转移脚本重复处理。 转移脚本与队列处理 监控是持续运行的，迁移则是定期手动触发（比如一个月或半年一次）。转移脚本读取 pending.json ，把存档从 AppData 搬走，原地建符号链接。 1. 转移脚本设计要点 从 pending.json 读取待处理项。 对每一项，先确定目标目录名。优先使用手动填写的 remark ，否则从解码后的 exe 路径自动提取游戏文件夹名，若都失败则回退到原始目录名。 通过 robocopy 将源目录完整复制到 D:\GameSaves\目标名 。 复制成功后， 删除源目录 ，并在同一位置创建一个 目录链接 指向新路径。 将迁移关系记录到 Markdown 格式的日志文件 存档迁移记录.md 中。 处理成功的条目从队列移除，失败则保留，等待下次重试。 2. 几个关键设计 安全删除和链接创建 ，这是最容易翻车的环节，有两个点必须处理好： 复制前如果目标目录已存在 （比如之前迁移过但记录丢了），直接 robocopy 会合并文件，可能造成新旧存档混杂。必须先尝试删除已有目标目录，并 检查是否真的被删干净 ；若因文件占用无法完全删除，则中止本次操作，保留队列项。 复制后删除源目录时，同样可能因文件占用导致部分删除失败 。必须确认源目录已完全消失后，才能创建链接。否则残留目录加上失败的链接创建，会让游戏存档状态混乱。若删除失败，整个迁移视为未完成，保留在队列中,下次重试。 这些检查在脚本中都是以条件判断 + 日志记录的方式实现的，确保一定成功。 迁移记录以 Markdown 表格形式写入 存档迁移记录.md ，例如: 原 C 盘快捷方式名 实际存储位置 游戏/说明 praygame D:\GameSaves\祈愿游戏 praygame 游戏存档 rmmz-game D:\GameSaves\莉可的不可思议差事 莉可的不可思议差事 这样无论后续手动浏览还是用其他工具解析，都非常直观。 队列自动清理 ：每处理完一批，脚本生成一个新的 JSON 数组，只包含失败的项，覆盖写回 pending.json 。成功的自动消失，不需要手动编辑。 设置开机自启 使用 Windows 任务计划程序保证脚本在每次登录时自动运行。 操作步骤 打开“任务计划程序” （可以 Win+R 输入 taskschd.msc ）。 右侧点击 “创建任务” （不是“创建基本任务”）。 名称： GameSavesMonitor 配置： Windows 10 ，勾选 “使用最高权限运行” 。 触发器 → 新建： 开始任务： 登录时 特定用户：选择你的账户（如 DESKTOP-XXX\admin ） 高级设置： 延迟任务时间 30 秒 （给网络驱动器映射留出时间） 确保“已启用”被勾选。 操作 → 新建： 程序或脚本： powershell.exe 添加参数： -WindowStyle Hidden -ExecutionPolicy Bypass -File "D:\Scripts\Watch-GameSaves.ps1" 起始于（可选）： D:\Scripts 条件 ：建议取消“只有在计算机使用交流电源时才启动此任务”（笔记本）。 设置 ：勾选“如果任务失败，按以下频率重新启动”（间隔 1 分钟，最多 3 次）。 确定保存。 验证自启是否生效 重启电脑后登录， Win+R 输入 taskschd.msc 查看 显示所有正在运行的任务 。 检查日志文件 D:\GameSaves\监控调试日志.txt ，应包含最新的启动时间戳。 总结 通过这套方案，无论游戏安装在本地还是 NAS，只要启动游戏产生配置文件夹，脚本就会自动记录存档路径和对应的游戏 exe 位置（Base64 编码）,并利用任务计划程序实现开机自启，再配合手动或自动迁移脚本，基本可以保证AppData较为干净。 由于所有操作都在 AppData 内进行（删除、创建链接）， 直接贴出完整脚本容易导致佬们在不理解的情况下误操作，造成数据丢失 。因此本文只讲逻辑和关键点，佬们可以根据以上思路自行编写，或让 AI 辅助生成。真有需要的佬可以私信我，如果对某一块的实现细节感兴趣，也欢迎留言交流。 2 个帖子 - 2 位参与者 阅读完整话题

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 我做了一个开源小工具：M2M 它可以把网易云、QQ 音乐、酷狗、酷我的公开歌单迁移到 Apple Music。 在线体验： https://m2m.xinyu017722.workers.dev/ GitHub： GitHub - cunyu-wxy/M2M · GitHub 目前支持： 粘贴歌单链接自动识别平台 解析歌名、歌手、专辑和顺序 浏览器内连接 Apple Music 自动创建 Apple Music 歌单并导入歌曲 显示导入成功、失败和失败原因 不需要注册账号 后端不保存 Apple ID 或个人资料库数据 支持 Cloudflare Workers 自部署 这个项目的定位比较明确：中文音乐平台 → Apple Music。 目前还有一些限制，比如 Apple Music 匹配可能不准，酷狗部分分享页只能拿到预览曲目。如果你有解析失败的歌单链接，欢迎提 issue 或 PR，如果大家感兴趣欢迎多多fork哦。 1 个帖子 - 1 位参与者 阅读完整话题

服务器目前是 CentOS 7.8 新购服务器准备焕新辣，佬们推荐使用什么 Linux服务器系统 喵？ Rocky Linux AlmaLinux Ubuntu Server LTS Debian Stable Fedora Server CoreOS Alibaba Cloud Linux Oracle Linux Other 点击以查看投票。 目前在 Rocky 和 Ubuntu 之间徘徊喵 感觉 Rocky 更会符合 CentOS 的直觉， Ubuntu 则更省事，欢迎佬补充喵 1 个帖子 - 1 位参与者 阅读完整话题

来猜猜为什么薄荷炸了…… 怎么有人懒到几千万条日志一点不清理啊…… （我们还在迁移服务器，稍安勿躁） 16 个帖子 - 15 位参与者 阅读完整话题

初来乍到，有没有找到codex怎么迁移对话 6 个帖子 - 6 位参与者 阅读完整话题

https://www.githubstatus.com/incidents/fcj3088jg1wx 照这个趋势下去连 99%都守不住了，似乎自从迁移到 Azure 开始稳定性就变差了很多

https://www.githubstatus.com/incidents/fcj3088jg1wx 照这个趋势下去连 99%都守不住了，似乎自从迁移到 Azure 开始稳定性就变差了很多

https://www.githubstatus.com/incidents/fcj3088jg1wx 照这个趋势下去连 99%都守不住了，似乎自从迁移到 Azure 开始稳定性就变差了很多

https://www.githubstatus.com/incidents/fcj3088jg1wx 照这个趋势下去连 99%都守不住了，似乎自从迁移到 Azure 开始稳定性就变差了很多

https://www.githubstatus.com/incidents/fcj3088jg1wx 照这个趋势下去连 99%都守不住了，似乎自从迁移到 Azure 开始稳定性就变差了很多

https://www.githubstatus.com/incidents/fcj3088jg1wx 照这个趋势下去连 99%都守不住了，似乎自从迁移到 Azure 开始稳定性就变差了很多

https://www.githubstatus.com/incidents/fcj3088jg1wx 照这个趋势下去连 99%都守不住了，似乎自从迁移到 Azure 开始稳定性就变差了很多

https://www.githubstatus.com/incidents/fcj3088jg1wx 照这个趋势下去连 99%都守不住了，似乎自从迁移到 Azure 开始稳定性就变差了很多

https://www.githubstatus.com/incidents/fcj3088jg1wx 照这个趋势下去连 99%都守不住了，似乎自从迁移到 Azure 开始稳定性就变差了很多

我的o2 用节点拉起 Wi-Fi call，现在直接就能拉起来，还不掉。 要不要迁移到沃达丰去啊 1 个帖子 - 1 位参与者 阅读完整话题

最近搬家，迁移宽带的时候，运营商把家里的IPv4动态公网IP回收了，说是现在无论什么原因都不给IPv4公网IP。 没办法，让运营商给开了IPv6（你没看错，运营商默认不给开IPv6，投诉了2次才给开）。 但现在的问题是在外面，大部分地方使用的还是纯IPv4，这就导致了在大部分情况下，无法访问家里的资料。 上网查了一下，好像大概就是两种思路： 1、买一个域名，利用外部服务器做代理中转（包括CF，FRP这种好像都属于这种中转）。 这种方式，如果在中国买域名，就必须备案。如果在中国以外买了域名，可以不用备案，但是在中国无法访问。 2、使用内网穿透工具，比如ZeroTier等组建局域网。 这种方式，在一些设备上（比如安卓），会与VPN通道冲突。虽然可以使用类似exitnode的方式，但是现在中国运营商给的上传带宽，一言难尽，访问速率大打折扣。 这两种方式，虽然解决了数据通讯问题，但还是各有痛点在里面。 请问除了这两种之外，是否还有其他不记名方式，或者不影响VPN使用的方式，来解决IPv4和IPv6互通的问题？ 4 个帖子 - 2 位参与者 阅读完整话题

已将CHY公益站使用的MySQL迁移至 PostgreSQL 并配置了 Redis 作为缓存，至此，CHY公益站迈出向着稳定的第二步 10 个帖子 - 10 位参与者 阅读完整话题

IT之家 6 月 5 日消息，MiniMax 发布 Token Plan 升级与权益调整说明，就 M3 模型上线后的 Token Plan 计费切换、订阅权益保护与档位迁移方案进行说明。 MiniMax 表示： 我们收到大家关于 Token Plan 的许多反馈。 本次调整未能提前与大家充分沟通并详细说明 M3 对应的 Token Plan 计费和套餐变化，是我们工作不到位 。在老用户周限额等问题上处理也不够妥当，给一直支持我们的用户带来了困扰，请大家见谅。 M3 是一个更大尺寸、更加智能、多模态、拥有 1M 上下文的全新模型，它能够完成更加复杂的任务，也意味着需要更多的算力资源，需要全新的定价模式。M3 可以做越来越复杂的任务，自运行越来越长的时间，意味着单次调用的资源消耗指数提升，一次调用就可能消耗掉相当于过去多次调用的资源。继续沿用旧的计量口径，难以让每位用户都获得稳定一致的体验。同时 Token Plan 支持 MiniMax 多个模态的模型，我们收到许多用户反馈，希望能够将订阅额度自由使用到不同模态模型上。 因此我们将 Token Plan 切换到行业统一的 Token-Based 计量，让每个人按真实使用量获得对等价值，让 M3 的能力能够更稳定、可持续地交付到每位用户手中 。 为了尽快将 M3 交到大家手上，过去几周团队经历了高强度的工作，我们疏忽了提前与大家充分沟通，节奏上的取舍处理得不够周全，给一直信任和陪伴我们的老用户带来了困扰，非常抱歉。 MiniMax 官方表示，为了回馈订阅用户，现推出以下方案： 3.22 前购买、没有周限额的老用户，本次升级后 M2.7 和 M3 都将继续保持无周限额 3.22 - 本周五上午 10:00 前购买 Token Plan 的用户 ， 在有效订阅周期内，M3 周限额永久加赠 50% 为了让大家更加畅快地体验 M3 在长程复杂任务上的提升，我们于今晚（6 月 2 日）统一重置额度，并且在 M3 上线后的前 7 天内（6.1 - 6.7），所有订阅用户的 5 小时 / 周使用额度翻倍，详情可在控制台中查看 关于此前迁移方案中发放的补偿积分，有效期将从一个月自动修正为 1 年（自发放日起），本周陆续订正中，自动生效 老用户综合权益效果如下： 时段 无周限额老用户 6 月 5 日 10:00 前订阅的老用户 2026-06-01 至 06-07 5 小时额度 200% / 周限额 ∞ 5 小时额度 200% / 周限额 300% 2026-06-08 及之后 周限额 ∞ 周限额 150% MiniMax 官方承诺，用户原有的 M2.7 使用权益不会缩水，并且现在可以无缝使用 M3。IT之家附 Token Plan 迁移说明如下： 一、Plus / Max 档用户 价格不变，签约价继续生效。新方案下： M2.7 的 5 小时使用次数 +10% （不会变少） 新增 M3 的使用权限 ，与 M2.7 共享同一份额度池 新增 多模态权益 ：图像、语音、音乐都可在同一份额度内调用 当前自动切换，无需任何操作。 二、Starter 29 元 / Plus-极速 98 元（保留档） 这两档继续保留， 价格和签约关系不变 ，但 仅对老用户开放 —— 新方案上线后不再对新用户售卖。 M2.7 的使用次数 约增加 10% 新增 M3 使用权限和多模态额度，与 M2.7 共享同一份额度池 这两档为老用户专属保留档，建议保持订阅状态以延续当前权益；若中途断订，后续将无法再次订阅同档套餐。当前自动切换，无需任何操作。 三、停售档位用户（Max-极速 199 元/ Ultra-极速 899 元） 这两档将停售。我们提供了 月费下降但权益不缩水 的迁移方案： Max-极速 ¥199 → 新 Max ¥119 ：月费下调 ¥80，每月额外补发 价值约 ¥160 的积分 用于覆盖差价，叠加多模态权益 Ultra-极速 ¥899 → 新 Ultra ¥469 ：月费下调 ¥430，每月额外补发 价值约 ¥860 的积分 用于覆盖差价，含每日 5 条视频额度 下个续费日自动转入新档，你也可以主动选择其他档位或退订。 四、年包用户 已付费月份的权益保护原则： M2.7 次数不缩水 + 多模态权益全部保留 ，年付折扣率延续。 停售档年包（Max-极速年包 / Ultra-极速年包） ：差价补偿不会一次性发放，而是 按订阅时间每月独立补发等值积分 （每月独立有效期 1 年，不滚存），确保整年权益不缩水。举例说明： Ultra-极速 ¥899 / 月年包（剩余 8 个月） ：每月按订阅日切到新 Ultra ¥469 权益，并每月补发 价值约 ¥860 的积分 （¥430 差价 ×2），连续补 8 个月，至年包到期日。年包到期后按新 Ultra ¥469 年付价自动续约，可继续享年付折扣。 Max-极速 ¥199 / 月年包（剩余 6 个月） ：每月按订阅日切到新 Max ¥119 权益，并每月补发 价值约 ¥160 的积分 （¥80 差价 ×2），连续补 6 个月。 五、新增 Ultra 469 元重度档 填补 ¥199 与 ¥899 之间的空缺，适合重度 agentic 用户。月度容量约 71 亿 token，含每日 5 条视频生成额度。 六、关于积分使用说明 1,000 积分 = ¥7 （与 API 按量付费 1:1 等价，无加价） MiniMax 开放平台所有模型均可使用 ，按各模型 API 按量付费刊例价实时扣减 跨模态共享 ：文本、图像、语音、音乐、视频（部分档位）均从同一份积分池消耗

应该没问题了 跟我的9900x说去吧 地址 muyuan.do 不要在我这里浪费时间，去做你该做的事情，去爱你该爱的人 93 个帖子 - 92 位参与者 阅读完整话题

服务器将在今晚七点进行迁移升级，预计需要半小时至一小时，请大家稍作等待 迁移完成会通知的大家 60 个帖子 - 60 位参与者 阅读完整话题