[BUG] crypt指向的目标路径失效时会导致重启，并且无法进入存储管理界面

[Lyviecs]

请确认以下事项

• 我已确认阅读并同意 AGPL-3.0 第15条 。
  本程序不提供任何明示或暗示的担保，使用风险由您自行承担。

• 我已确认阅读并同意 AGPL-3.0 第16条 。
  无论何种情况，版权持有人或其他分发者均不对使用本程序所造成的任何损失承担责任。

• 我确认我的描述清晰，语法礼貌，能帮助开发者快速定位问题，并符合社区规则。

• 我已确认阅读了OpenList文档。

• 我已确认没有重复的问题或讨论。

• 我已确认是OpenList的问题，而不是其他原因（例如 网络 ，依赖或操作）。

• 我认为此问题必须由OpenList处理，而非第三方。

• 我已确认这个问题在最新版本中没有被修复。

OpenList 版本（必填）

v4.1.7

使用的存储驱动（必填）

crypt

问题描述（必填）

因为网络原因，我短暂失去了与夸克网盘的连接，这导致先前设置的crypt驱动指向了一个空目标
开始没有意识到原因
后来网络恢复后我发现openlist主页面加载非常慢，怀疑还是因为网络原因，导致从网盘获取详细信息延迟过高
因此逐个关闭了多个云盘来测试加载速度
不经意间，在夸克网盘驱动未开启的情况下点击了crypt驱动的启用按钮
然后复现了最初无限重启的错误
现在我可以进入管理界面，但是不能进入主界面和存储管理界面，所以我失去了对openlist的访问

日志（必填）

openlist | panic: runtime error: invalid memory address or nil pointer dereference
openlist |
openlist | runtime/debug.Stack()
openlist | /opt/hostedtoolcache/go/1.25.0/x64/src/runtime/debug/stack.go:26 +0x64
openlist | github.com/OpenListTeam/OpenList/v4/pkg/singleflight.newPanicError({0x235c180, 0x81c8450})
openlist | /home/runner/work/OpenList/OpenList/pkg/singleflight/singleflight.go:44 +0x24
openlist | github.com/OpenListTeam/OpenList/v4/pkg/singleflight.(*Group[...]).doCall.func2.1()
openlist | /home/runner/work/OpenList/OpenList/pkg/singleflight/singleflight.go:193 +0x3c
openlist | panic({0x235c180?, 0x81c8450?})
openlist | /opt/hostedtoolcache/go/1.25.0/x64/src/runtime/panic.go:783 +0x120
openlist | github.com/OpenListTeam/OpenList/v4/internal/op.GetStorageDetails({0x6bf62d8, 0x40006649a0}, {0x0, 0x0}, {0x0, 0x0, 0x5?})
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:451 +0x38
openlist | github.com/OpenListTeam/OpenList/v4/drivers/crypt.(*Crypt).GetDetails(0x400073fc68?, {0x6bf62d8?, 0x40006649a0?})
openlist | /home/runner/work/OpenList/OpenList/drivers/crypt/driver.go:415 +0x40
openlist | github.com/OpenListTeam/OpenList/v4/internal/op.GetStorageDetails.func1()
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:464 +0x34
openlist | github.com/OpenListTeam/OpenList/v4/pkg/singleflight.(*Group[...]).doCall.func2(0x4000142d70, 0x8af2cae84fbd5a68, 0x41afac?)
openlist | /home/runner/work/OpenList/OpenList/pkg/singleflight/singleflight.go:198 +0x54
openlist | github.com/OpenListTeam/OpenList/v4/pkg/singleflight.(*Group[...]).doCall(0x4000805590?, 0x4000aad940?, {0x4000aad940?, 0x4000a14300?}, 0x6c1cda0?)
openlist | /home/runner/work/OpenList/OpenList/pkg/singleflight/singleflight.go:200 +0x80
openlist | github.com/OpenListTeam/OpenList/v4/pkg/singleflight.(*Group[...]).Do(0x6c241c0, {0x4000aad940, 0x7}, 0x400073fda8)
openlist | /home/runner/work/OpenList/OpenList/pkg/singleflight/singleflight.go:113 +0x1b8
openlist | github.com/OpenListTeam/OpenList/v4/internal/op.GetStorageDetails({0x6bf62d8, 0x40006649a0}, {0x6c05758, 0x4000b48000}, {0x400073fe77, 0x1, 0x0?})
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:463 +0x280
openlist | github.com/OpenListTeam/OpenList/v4/internal/op.GetStorageVirtualFilesWithDetailsByPath.func1({0x6c05758, 0x4000b48000}, {0x6c038d8, 0x4000a93880})
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:363 +0x158
openlist | github.com/OpenListTeam/OpenList/v4/internal/op.getStorageVirtualFilesByPath.func2()
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:410 +0x7c
openlist | created by github.com/OpenListTeam/OpenList/v4/internal/op.getStorageVirtualFilesByPath in goroutine 103
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:408 +0x564
openlist |
openlist |
openlist | goroutine 106 [running]:
openlist | github.com/OpenListTeam/OpenList/v4/pkg/singleflight.(*Group[...]).doCall.func1()
openlist | /home/runner/work/OpenList/OpenList/pkg/singleflight/singleflight.go:170 +0x298
openlist | github.com/OpenListTeam/OpenList/v4/pkg/singleflight.(*Group[...]).doCall(0x4000805590?, 0x4000aad940?, {0x4000aad940?, 0x4000a14300?}, 0x6c1cda0?)
openlist | /home/runner/work/OpenList/OpenList/pkg/singleflight/singleflight.go:205 +0xa0
openlist | github.com/OpenListTeam/OpenList/v4/pkg/singleflight.(*Group[...]).Do(0x6c241c0, {0x4000aad940, 0x7}, 0x400073fda8)
openlist | /home/runner/work/OpenList/OpenList/pkg/singleflight/singleflight.go:113 +0x1b8
openlist | github.com/OpenListTeam/OpenList/v4/internal/op.GetStorageDetails({0x6bf62d8, 0x40006649a0}, {0x6c05758, 0x4000b48000}, {0x400073fe77, 0x1, 0x0?})
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:463 +0x280
openlist | github.com/OpenListTeam/OpenList/v4/internal/op.GetStorageVirtualFilesWithDetailsByPath.func1({0x6c05758, 0x4000b48000}, {0x6c038d8, 0x4000a93880})
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:363 +0x158
openlist | github.com/OpenListTeam/OpenList/v4/internal/op.getStorageVirtualFilesByPath.func2()
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:410 +0x7c
openlist | created by github.com/OpenListTeam/OpenList/v4/internal/op.getStorageVirtualFilesByPath in goroutine 103
openlist | /home/runner/work/OpenList/OpenList/internal/op/storage.go:408 +0x564
openlist exited with code 2

配置文件内容（必填）

尝试删除配置文件config无效，现在是自动生成的默认配置

复现链接（可选）

No response

[github-actions]

感谢您联系OpenList。我们会尽快回复您。
Thanks for contacting OpenList. We will reply to you as soon as possible.

[Lyviecs]

另外，我尝试更改账号权限，使得加载主界面时不会访问crypt所在位置，目前可以正常加载

[jyxjjj]

这是一个已知问题。原本由于网络原因引起的情况不在我们的考虑范围内，但鉴于目前有部分提交确实在优化相关体验，我们会考虑将其纳入修改范围。

另外，根据AGPL协议第15条，我认为你应该自行修改数据库文件，或尝试恢复网络连接。同时提醒你配置文件与驱动无关。

[Lyviecs]

这是一个已知问题。原本由于网络原因引起的情况不在我们的考虑范围内，但鉴于目前有部分提交确实在优化相关体验，我们会考虑将其纳入修改范围。

另外，根据AGPL协议第15条，我认为你应该自行修改数据库文件，或尝试恢复网络连接。同时提醒你配置文件与驱动无关。

好的，我明白你的意思，我会尝试自行解决问题

反馈中提到网络连接只是在描述问题出现时的情况并提供复现的可能
原谅我表述不清，我实际想要提出的是两个点
1.crypt在未能正常启动时似乎没有自动禁用
2.能否在后续更新中考虑在“序号”的方式以外，增加类似“依赖”的启动顺序方案，避免crypt这种可能依赖于其他挂载的驱动指向为空造成错误

另外，提到配置文件是因为这在反馈提交过程中是必填项，再次抱歉

[jyxjjj]

反馈中提到网络连接只是在描述问题出现时的情况并提供复现的可能 原谅我表述不清，我实际想要提出的是两个点 1.crypt在未能正常启动时似乎没有自动禁用 2.能否在后续更新中考虑在“序号”的方式以外，增加类似“依赖”的启动顺序方案，避免crypt这种可能依赖于其他挂载的驱动指向为空造成错误

序号功能本身就存在的

[jyxjjj]

另外，提到配置文件是因为这在反馈提交过程中是必填项，再次抱歉

我的意思是“尝试删除配置文件config无效，现在是自动生成的默认配置” 对于你的问题来说没意义，你不如就给一下默认配置

[jyxjjj]

反馈中提到网络连接只是在描述问题出现时的情况并提供复现的可能 原谅我表述不清，我实际想要提出的是两个点 1.crypt在未能正常启动时似乎没有自动禁用 2.能否在后续更新中考虑在“序号”的方式以外，增加类似“依赖”的启动顺序方案，避免crypt这种可能依赖于其他挂载的驱动指向为空造成错误

序号功能本身就存在的

确实可以测下序号能不能解决，我记得可以

[jyxjjj]

#539 (comment)

[Lyviecs]

反馈中提到网络连接只是在描述问题出现时的情况并提供复现的可能 原谅我表述不清，我实际想要提出的是两个点 1.crypt在未能正常启动时似乎没有自动禁用 2.能否在后续更新中考虑在“序号”的方式以外，增加类似“依赖”的启动顺序方案，避免crypt这种可能依赖于其他挂载的驱动指向为空造成错误

序号功能本身就存在的

我在先前回复中提到的“crypt在未能正常启动时似乎没有自动禁用”，这一描述并不准确
我查看日志后发现，指向为空会直接导致panic宕机，这似乎发生在openlist本身而非简单的存储驱动启动失败的问题
这是否算是某种“泄露”？
宕机意味着主程序根本无法将crypt驱动作无效处理，而openlist会自动尝试重启，并再度触发宕机，就此循环

我知道有“序号”功能，并且有正常配置，将crypt功能放在最后的顺序
但是“序号”功能只是延迟启动，不能实现“关联”

启用crypt需要指定已有的位置，也就是说，crypt很多情况下是依赖另一个存储这一“前提”来工作的
换言之，“关联”实际存在，但是openlist启动时只按照顺序进行，不会对“前提”的有效性进行判定，这导致“序号”功能并不能解决网络或磁盘物理损坏等原因导致crypt指向空这个问题

因此这个issues似乎应该算作一个bug和一个对应的feature？我不确定是否应该分开重新进行提案

另，我通过数据库编辑删除了出错的crypt驱动，已经恢复正常使用，确定配置文件与此无关

[Lyviecs]

1号存储A出现错误，对应的99号crypt仍然会尝试启动
如果使用depends_on的方式，就可以让crypt在对应存储失效时跳过启动，而非尝试后再报错
这样无法彻底解决空指针宕机，但是可以避免触发这种情况

[jyxjjj]

那我重新打开，明天看一下