刚开始接触照片管理服务，对这里面的逻辑不太了解。网上的教程都是如何安装immich和如何上传照片这些，但没有介绍immich是如何组织照片的存储的。
个人上传照片后，发现在upload目录里"乱七八糟"的存放着照片文件，第一层是immich user的uuid这个可以理解，后面的层级实在是让强迫症呕血，连照片文件名都变了，这就完全没法自己管理上传的照片了，只能从immich操作。这实在是让人接受不了。
后来在网上看到《Immich的优缺点 // 喵ฅ^•ﻌ•^ฅ (ruohai.wang)》这位大神的帖子中有部分提及，摘抄如下：
--------------------------------------------------------------------
我使用immich的一个星期里，这个bug碰到了两次。具体表现是，上传以后的照片，卡在upload目录无法归档。这个bug我觉得非常的致命。
这里说一下immich处理照片整个流程：
上传的照片全部用uuid重命名，保存到upload目录。这个目录可以理解为临时目录，所有上传的照片都临时放这里等待处理。
然后会跑extract metadata任务开始读取upload目录下照片的元数据。
读取完以后，根据照片拍摄时间把文件归档并还原文件名
上传的照片卡在upload目录的意思，就是extract metadata任务出了问题。我碰到的两次bug，一次是extract metadata任务无法运行，一直是pause状态，点击resume/start以后立刻就会变成pause，upload目录留了1800张照片无法处理。第二次bug是extract metadata任务能正常跑，但upload目录里它就是留了11张照片不处理。
如果你有很强的debug能力，那可以自己想办法处理。如果有足够的耐心，那可以上immich的github项目主页去提issue，然后等维护人员解答。
如果以上两个方案都无法接受，只想立刻解决这个bug，比如重新部署immich然后把卡在upload目录的照片拿出来重新导入一遍，那最致命的问题来了：留在upload目录的照片，文件名是被重命名过的，不仅丢失了原文件名，而且uuid的格式毫无辨识度。重新导入以后，甚至连归档时间都会被重置，也就是识别成此时此刻，然后归档到当天。
这种bug碰到一次就想死了，碰到两次，拜拜了immich。
-----------------------------------------------------------------------------------
大神这里是在说，upload其实是个临时目录，最终照片文件还是会被还原为原来的文件名，但大神也没说还原了以后的照片存在哪里，而且大神用了“归档”这个词，似乎也不太准确，因为immich里的“归档”对应的是archive这个操作吧，首先这是个类似于隐藏照片的功能，更像是个删除，其次archive也不是自动执行的，是手动的吧。。。
如果先抛开上面这个问题，那我上传照片并且后台job都完成后的状态就是：upload和thumbs里有内容，library里面是空的，那按照大神的说法，我这个也是extract metdata任务出了问题？
所以想请问一下大家，自己手动上传的照片，最终在immich的存储里，文件结构是怎样的？library文件夹里为什么会是空的？
个人上传照片后，发现在upload目录里"乱七八糟"的存放着照片文件，第一层是immich user的uuid这个可以理解，后面的层级实在是让强迫症呕血，连照片文件名都变了，这就完全没法自己管理上传的照片了，只能从immich操作。这实在是让人接受不了。
后来在网上看到《Immich的优缺点 // 喵ฅ^•ﻌ•^ฅ (ruohai.wang)》这位大神的帖子中有部分提及，摘抄如下：
--------------------------------------------------------------------
我使用immich的一个星期里，这个bug碰到了两次。具体表现是，上传以后的照片，卡在upload目录无法归档。这个bug我觉得非常的致命。
这里说一下immich处理照片整个流程：
上传的照片全部用uuid重命名，保存到upload目录。这个目录可以理解为临时目录，所有上传的照片都临时放这里等待处理。
然后会跑extract metadata任务开始读取upload目录下照片的元数据。
读取完以后，根据照片拍摄时间把文件归档并还原文件名
上传的照片卡在upload目录的意思，就是extract metadata任务出了问题。我碰到的两次bug，一次是extract metadata任务无法运行，一直是pause状态，点击resume/start以后立刻就会变成pause，upload目录留了1800张照片无法处理。第二次bug是extract metadata任务能正常跑，但upload目录里它就是留了11张照片不处理。
如果你有很强的debug能力，那可以自己想办法处理。如果有足够的耐心，那可以上immich的github项目主页去提issue，然后等维护人员解答。
如果以上两个方案都无法接受，只想立刻解决这个bug，比如重新部署immich然后把卡在upload目录的照片拿出来重新导入一遍，那最致命的问题来了：留在upload目录的照片，文件名是被重命名过的，不仅丢失了原文件名，而且uuid的格式毫无辨识度。重新导入以后，甚至连归档时间都会被重置，也就是识别成此时此刻，然后归档到当天。
这种bug碰到一次就想死了，碰到两次，拜拜了immich。
-----------------------------------------------------------------------------------
大神这里是在说，upload其实是个临时目录，最终照片文件还是会被还原为原来的文件名，但大神也没说还原了以后的照片存在哪里，而且大神用了“归档”这个词，似乎也不太准确，因为immich里的“归档”对应的是archive这个操作吧，首先这是个类似于隐藏照片的功能，更像是个删除，其次archive也不是自动执行的，是手动的吧。。。
如果先抛开上面这个问题，那我上传照片并且后台job都完成后的状态就是：upload和thumbs里有内容，library里面是空的，那按照大神的说法，我这个也是extract metdata任务出了问题？
所以想请问一下大家，自己手动上传的照片，最终在immich的存储里，文件结构是怎样的？library文件夹里为什么会是空的？
