op带刷新put，115open的put返回值少了吧，感觉是这个原因。

115open现在复制操作已经能成功执行了，并且会清除目标目录的缓存（或跳过缓存），导致如果目录中有几千个文件，就会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

op带刷新put，115open的put返回值少了吧，感觉是这个原因。

我看代码有两种情况，返回带上传成功文件信息的会加到缓存，没有的就不加。115_open 走的是这一段

op带刷新put，115open的put返回值少了吧，感觉是这个原因。

我看代码有两种情况，返回带上传成功文件信息的会加到缓存，没有的就不加。115_open 走的是这一段

OpenList/internal/op/fs.go

Line 574 in b4997e7

case driver.Put:

我是看旧驱动上传完要获取下新文件，我也不确定。115账号用接码平台，限速后卸载了。

115open现在复制操作已经能成功执行了，并且会清除目标目录的缓存（或跳过缓存），导致如果目录中有几千个文件，就会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

出于这个原因，原本设计就是懒加载手动刷新。

115open现在复制操作已经能成功执行了，并且会清除目标目录的缓存（或跳过缓存），导致如果目录中有几千个文件，就会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

此pr就是在复制或者其他操作完成后，缓存需要刷新的目录，正常来讲只会重新拉取一次目录

115open现在复制操作已经能成功执行了，并且会清除目标目录的缓存（或跳过缓存），导致如果目录中有几千个文件，就会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

此pr就是在复制或者其他操作完成后，缓存需要刷新的目录，正常来讲只会重新拉取一次目录

多文件上传同一文件夹就一直刷新，那不如直接删了懒加载的判断条件强制刷新(会风控)。

115open现在复制操作已经能成功执行了，并且会清除目标目录的磁盘（或跳过磁盘），导致如果目录中有数千个文件，则会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

此pr完成就是在复制或者其他操作后，缓存需要刷新的目录，正常的话只需重新拉取一次目录

感谢解释这个 PR 的作用。我明白，如果你不访问这个文件夹就不会请求网盘。在一些使用场景中（115open 驱动 + WebDAV 挂载客户端），目录下有几千个视频文件时：

如果有一个文件，或多个，秒传到这个文件夹，客户端WebDAV访问、下载或重命名它时，整个目录都会重新拉取，可能需要 7~8 秒才能加载完所有文件。

但在同样的环境下，使用 115 驱动时：
客户端操作（访问/下载/重命名）这个文件时，只会拉取这个单文件的元数据？或者直接有这个文件的缓存？，耗时不到零点几秒。

这种目录刷新行为的差异，对于处理大目录的用户来说影响很大。目前 115open 的实现似乎会在秒传成功变更时，用户访问，触发全目录刷新，而 115 驱动的处理方式更高效。

115open现在复制操作已经能成功执行了，并且会清除目标目录的磁盘（或跳过磁盘），导致如果目录中有数千个文件，则会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

此pr完成就是在复制或者其他操作后，缓存需要刷新的目录，正常的话只需重新拉取一次目录

感谢解释这个 PR 的作用。在我的使用场景中（115open 驱动 + WebDAV 挂载客户端），目录下有几千个视频文件时：

如果有一个文件秒传到这个文件夹，客户端WebDAV访问、下载或重命名它时，整个目录都会重新拉取，可能需要 7~8 秒才能加载完所有文件。

但在同样的环境下，使用 115 驱动时： 如果秒传一个文件到该目录，客户端操作（访问/下载/重命名）这个文件时，只会拉取这个单文件的元数据？或者直接有这个文件的缓存？，耗时不到零点几秒。

这种目录刷新行为的差异，对于处理大目录的用户来说影响很大。目前 115open 的实现似乎会在任何变更时触发全目录刷新，而 115 驱动的处理方式更高效。

115驱动上传会返回该文件信息加上原先缓存的文件，因此不需要重新获取文件列表，115open不会(应该不支持)所以需要手动刷新重新获取文件列表。

115open现在复制操作已经能成功执行了，并且会清除目标目录的磁盘（或跳过磁盘），导致如果目录中有数千个文件，则会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

此pr完成就是在复制或者其他操作后，缓存需要刷新的目录，正常的话只需重新拉取一次目录

感谢解释这个 PR 的作用。在我的使用场景中（115open 驱动 + WebDAV 挂载客户端），目录下有几千个视频文件时：
如果有一个文件秒传到这个文件夹，客户端WebDAV访问、下载或重命名它时，整个目录都会重新拉取，可能需要 7~8 秒才能加载完所有文件。
但在同样的环境下，使用 115 驱动时： 如果秒传一个文件到该目录，客户端操作（访问/下载/重命名）这个文件时，只会拉取这个单文件的元数据？或者直接有这个文件的缓存？，耗时不到零点几秒。
这种目录刷新行为的差异，对于处理大目录的用户来说影响很大。目前 115open 的实现似乎会在任何变更时触发全目录刷新，而 115 驱动的处理方式更高效。

115驱动上传会返回该文件信息加上原先缓存的文件，因此不需要重新获取文件列表，115open不会(应该不支持)所以需要手动刷新重新获取文件列表。

感谢你的详细解释，我完全理解了这个问题的核心原因。115 驱动能直接利用上传返回的文件信息并结合现有缓存，避免了全目录刷新，而 115open 目前需要手动触发重新获取文件列表，导致大目录下的性能差异。

115open现在复制操作已经能成功执行了，并且会清除目标目录的缓存（或跳过缓存），导致如果目录中有几千个文件，就会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

此pr就是在复制或者其他操作完成后，缓存需要刷新的目录，正常来讲只会重新拉取一次目录

多文件上传同一文件夹就一直刷新，那不如直接删了懒加载的判断条件强制刷新(会风控)。

只有访问文件夹的时候才会刷新吧 ，多文件移动的时候也会

115open现在复制操作已经能成功执行了，并且会清除目标目录的缓存（或跳过缓存），导致如果目录中有几千个文件，就会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

此pr就是在复制或者其他操作完成后，缓存需要刷新的目录，正常来讲只会重新拉取一次目录

多文件上传同一文件夹就一直刷新，那不如直接删了懒加载的判断条件强制刷新(会风控)。

只有访问文件夹的时候才会刷新吧

上传文件前要确认该文件是否存在，还是要获取文件列表吧。

115open现在复制操作已经能成功执行了，并且会清除目标目录的缓存（或跳过缓存），导致如果目录中有几千个文件，就会全部从网盘重新拉取，可能引发性能问题。115驱动则没有这个问题

此pr就是在复制或者其他操作完成后，缓存需要刷新的目录，正常来讲只会重新拉取一次目录

多文件上传同一文件夹就一直刷新，那不如直接删了懒加载的判断条件强制刷新(会风控)。

只有访问文件夹的时候才会刷新吧

上传文件前要确认该文件是否存在，还是要获取文件列表吧。

确实是，之前对代码还不是很熟悉。现在除了强制刷新的话，暂时没想到更好的办法。