Greasy Fork

可以加入下载过滤多少MB大小文件的选项吗？

可以加入下载过滤多少MB大小文件的选项吗？

可以，下载大小过滤功能已加入下个版本的更新计划

想问一下文件去重，是直接勾选筛选出来的文件它会自动保留一个原文件，还是要在表头中再筛选一次，他才会保留一个原文件

想问一下文件去重，是直接勾选筛选出来的文件它会自动保留一个原文件，还是要在表头中再筛选一次，他才会保留一个原文件

文件查重、文件夹查重模式，和普通模式一样，都是“勾选项 = 实际操作项”。

在查重模式里：

• 每个分组表头的勾选框，表示选中这一整组；
• “组内排序”只是把组内项目按时间 / 大小 / 路径 / 名称重新排序显示，不会自动决定删除谁、保留谁；
• “一键勾选”才会按规则自动处理，逻辑是：选中每个分组内除“保留项”以外的文件。

所以总结就是：

• 手动勾选：不会自动保留一个，需要你自己判断；
• 点击“一键勾选”：会按你选择的规则，每组自动保留 1 个，其余勾上。

查重模式本身不会自动删除文件，只是列出可能重复的项目。需要你自己判断并勾选，最后再点击删除，才会真正清理。

另外，文件查重中的“精准匹配”采用哈希值匹配，通常可较放心地配合“一键勾选”进行清理；而文件查重中的“时长相似 / 名称相似”以及文件夹查重，均属于相似算法匹配，建议在清理前先人工确认，谨慎操作。

您好，我想反馈一个新问题就是文件批量删除后,然后然后发现数量正确，但是文件回不到原来的文件夹,等于就是乱的。请问是我的操作有误吗

请问这样的情况有办法一键恢复吗

请问这样的情况有办法一键恢复吗

您好，我理解您的问题是：批量删除后，文件数量看起来是正确的，但文件所在的文件夹位置变乱了，部分文件没有显示在原来的目录中。

这个情况需要先确认具体操作流程，暂时还不能判断是脚本操作问题、PikPak 官方数据同步问题，还是脚本缓存/索引显示问题。

麻烦您补充一下：

1. 当时使用的是哪个功能删除？普通删除、彻底删除、查重删除、黑名单清理，还是其他批量功能？
2. 删除发生在哪个页面？普通文件夹、查重结果、搜索结果、最近添加、收藏夹，还是文件/文件夹分析页面？
3. 删除后是否有进行过“恢复”操作？如果有，是从回收站恢复的吗？
4. 在 PikPak 官方网页或 App 中查看，文件位置也是乱的吗？还是只有脚本界面显示异常？
5. 如果方便，请提供一下操作步骤和截图，我会根据具体流程继续排查。

目前先不要继续大量移动或删除这些文件，避免后续更难还原原始目录关系。

情况如下①删除的情况发生在文件查重以后。使用精准匹配，等重复的文件集合到脚本的回收站页面，然后清空脚本网页回收站
②删除之后有恢复操作，因文件数量较多，所以想核对，故分别从脚本回收站和官方软件回收站中都有恢复操作
③从官方软件网页及脚本这三者分别查看部分文件都不在原文件夹中，去重应该是成功了的，数量正常

情况如下①删除的情况发生在文件查重以后。使用精准匹配，等重复的文件集合到脚本的回收站页面，然后清空脚本网页回收站②删除之后有恢复操作，因文件数量较多，所以想核对，故分别从脚本回收站和官方软件回收站中都有恢复操作③从官方软件网页及脚本这三者分别查看部分文件都不在原文件夹中，去重应该是成功了的，数量正常

您好，经过进一步复现测试，这种情况不是您的操作有误，也并非脚本逻辑缺失，更接近 PikPak 官方回收站还原机制在“虚拟路径”下的表现。

测试发现：当文件是在虚拟路径中被批量删除时，例如官方的收藏夹、最近添加，以及脚本中的文件透视、文件查重、文件夹透视、文件夹查重等跨目录聚合视图，这些文件本身可能来自多个不同的原始文件夹。删除后再从回收站还原时，官方还原机制可能不会逐个还原到原始父目录，而是把大量文件集中还原到某一个统一目录中，导致原来的多层级目录结构被破坏。

因此，这类情况目前无法保证一键恢复到原目录结构。建议后续在虚拟路径或聚合结果页中批量删除文件前，先仔细确认是否确实不再需要；如果文件来自多个不同目录，尽量避免“批量删除后再通过回收站还原”的操作。

普通真实目录中的删除和还原，在目前测试中是正常的。