[BUG] assets may become orphaned when moved by the storage template service #978

New Issue

OVERLORD · 2026-02-04T23:45:42+03:00

OVERLORD commented

2026-02-04 23:45:42 +03:00

Originally created by @uhthomas on GitHub (Jun 20, 2023).

The bug

I uploaded 8.5k files to Immich with the CLI and waited for all the jobs to process. Things look mostly fine, except some assets are missing thumbnails.

A look at the jobs status page shows some did fail.

Any attempt to rerun those jobs fail, and the logs from the microservice show:

immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7  - 06/20/2023, 3:37:51 PM   ERROR [JobService] Unable to run job handler: Error: Input file is missing: upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/acb63ba0-9693-46e4-a63c-5c58f8060def.ARW
immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7  - 06/20/2023, 3:37:51 PM   ERROR [JobService] Error: Input file is missing: upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/acb63ba0-9693-46e4-a63c-5c58f8060def.ARW
immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7  - 06/20/2023, 3:37:51 PM   ERROR [JobService] Object:
immich-microservice-bcb587fdb-wf4tr immich-microservice {
immich-microservice-bcb587fdb-wf4tr immich-microservice   "id": "75b70416-fd3c-414a-8957-5ad936ce4946"
immich-microservice-bcb587fdb-wf4tr immich-microservice }
immich-microservice-bcb587fdb-wf4tr immich-microservice
immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7  - 06/20/2023, 3:37:51 PM   ERROR [JobService] Unable to run job handler: Error: Input file is missing: upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/4f26b42c-d230-4808-a338-a048f529c5c6.ARW
immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7  - 06/20/2023, 3:37:51 PM   ERROR [JobService] Error: Input file is missing: upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/4f26b42c-d230-4808-a338-a048f529c5c6.ARW
immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7  - 06/20/2023, 3:37:51 PM   ERROR [JobService] Object:
immich-microservice-bcb587fdb-wf4tr immich-microservice {
immich-microservice-bcb587fdb-wf4tr immich-microservice   "id": "a4aa15df-b5a2-4506-9762-d192a1449830"
immich-microservice-bcb587fdb-wf4tr immich-microservice }
immich-microservice-bcb587fdb-wf4tr immich-microservice

A manual storage template migration also shows similar logs:

immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7  - 06/20/2023, 4:02:51 PM   ERROR [StorageTemplateService] Problem applying storage template
immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7  - 06/20/2023, 4:02:51 PM   ERROR [StorageTemplateService] Error: ENOENT: no such file or directory, rename 'upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/ace1c10d-3a30-4c61-9f66-7461370cdb6f.ARW' -> 'upload/library/admin/2022/2022-11-24/_DSC5135+1.ARW'
immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7  - 06/20/2023, 4:02:51 PM   ERROR [StorageTemplateService] Object:
immich-microservice-bcb587fdb-wf4tr immich-microservice {
immich-microservice-bcb587fdb-wf4tr immich-microservice   "id": "7dbecbbe-2cdb-4ef8-aae6-8d780db4a452",
immich-microservice-bcb587fdb-wf4tr immich-microservice   "source": "upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/ace1c10d-3a30-4c61-9f66-7461370cdb6f.ARW",
immich-microservice-bcb587fdb-wf4tr immich-microservice   "destination": "upload/library/admin/2022/2022-11-24/_DSC5135+1.ARW"
immich-microservice-bcb587fdb-wf4tr immich-microservice }

Further, it's not possible to download the image. Though interestingly there is exif data.

Server logs from this action:

immich-server-688c95f58d-bs56b immich-server [Nest] 7  - 06/20/2023, 4:24:16 PM   ERROR [ExceptionsHandler] ENOENT: no such file or directory, stat 'upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/f1801892-ed57-47d9-bc57-f699f31ffaf8.ARW'
immich-server-688c95f58d-bs56b immich-server Error: ENOENT: no such file or directory, stat 'upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/f1801892-ed57-47d9-bc57-f699f31ffaf8.ARW'

A manual inspection of the filesystem shows the image was successfully moved, but the change was not persisted to the database. The image was supposed to be moved back, but wasn't.

/usr/src/app $ find upload -name '_DSC4726*'
upload/library/admin/2022/2022-11-23/_DSC4726.ARW
/usr/src/app $ find upload -name '63a658d3-c110-42e1-8621-7e345cfda737/f1801892-ed57-47d9-bc57-f699f31ffaf8*'
/usr/src/app $

Loki shows there were some issues connecting to the database, which isn't Immich's fault but Immich should handle this better.

The OS that Immich Server is running on

Kubernetes

Version of Immich Server

v1.61.1

Version of Immich Mobile App

N/A

Platform with the issue

Server
Web
Mobile

Your docker-compose.yml content

N/A

Your .env content

N/A

Reproduction steps

N/A

Additional information

No response

Originally created by @uhthomas on GitHub (Jun 20, 2023). ### The bug I uploaded 8.5k files to Immich with the CLI and waited for all the jobs to process. Things look mostly fine, except some assets are missing thumbnails. ![image](https://github.com/immich-app/immich/assets/9749173/e689c90f-200e-4a74-8cf3-ba2045ac54e4) A look at the jobs status page shows some did fail. ![image](https://github.com/immich-app/immich/assets/9749173/62dc5bc5-71b0-46ac-8860-0825e32363ed) Any attempt to rerun those jobs fail, and the logs from the microservice show: ```log immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7 - 06/20/2023, 3:37:51 PM ERROR [JobService] Unable to run job handler: Error: Input file is missing: upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/acb63ba0-9693-46e4-a63c-5c58f8060def.ARW immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7 - 06/20/2023, 3:37:51 PM ERROR [JobService] Error: Input file is missing: upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/acb63ba0-9693-46e4-a63c-5c58f8060def.ARW immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7 - 06/20/2023, 3:37:51 PM ERROR [JobService] Object: immich-microservice-bcb587fdb-wf4tr immich-microservice { immich-microservice-bcb587fdb-wf4tr immich-microservice "id": "75b70416-fd3c-414a-8957-5ad936ce4946" immich-microservice-bcb587fdb-wf4tr immich-microservice } immich-microservice-bcb587fdb-wf4tr immich-microservice immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7 - 06/20/2023, 3:37:51 PM ERROR [JobService] Unable to run job handler: Error: Input file is missing: upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/4f26b42c-d230-4808-a338-a048f529c5c6.ARW immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7 - 06/20/2023, 3:37:51 PM ERROR [JobService] Error: Input file is missing: upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/4f26b42c-d230-4808-a338-a048f529c5c6.ARW immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7 - 06/20/2023, 3:37:51 PM ERROR [JobService] Object: immich-microservice-bcb587fdb-wf4tr immich-microservice { immich-microservice-bcb587fdb-wf4tr immich-microservice "id": "a4aa15df-b5a2-4506-9762-d192a1449830" immich-microservice-bcb587fdb-wf4tr immich-microservice } immich-microservice-bcb587fdb-wf4tr immich-microservice ``` A manual storage template migration also shows similar logs: ```log immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7 - 06/20/2023, 4:02:51 PM ERROR [StorageTemplateService] Problem applying storage template immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7 - 06/20/2023, 4:02:51 PM ERROR [StorageTemplateService] Error: ENOENT: no such file or directory, rename 'upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/ace1c10d-3a30-4c61-9f66-7461370cdb6f.ARW' -> 'upload/library/admin/2022/2022-11-24/_DSC5135+1.ARW' immich-microservice-bcb587fdb-wf4tr immich-microservice [Nest] 7 - 06/20/2023, 4:02:51 PM ERROR [StorageTemplateService] Object: immich-microservice-bcb587fdb-wf4tr immich-microservice { immich-microservice-bcb587fdb-wf4tr immich-microservice "id": "7dbecbbe-2cdb-4ef8-aae6-8d780db4a452", immich-microservice-bcb587fdb-wf4tr immich-microservice "source": "upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/ace1c10d-3a30-4c61-9f66-7461370cdb6f.ARW", immich-microservice-bcb587fdb-wf4tr immich-microservice "destination": "upload/library/admin/2022/2022-11-24/_DSC5135+1.ARW" immich-microservice-bcb587fdb-wf4tr immich-microservice } ``` Further, it's not possible to download the image. Though interestingly there is exif data. ![image](https://github.com/immich-app/immich/assets/9749173/1a0185dc-2be3-410b-8ba8-67235a08fa5b) Server logs from this action: ```log immich-server-688c95f58d-bs56b immich-server [Nest] 7 - 06/20/2023, 4:24:16 PM ERROR [ExceptionsHandler] ENOENT: no such file or directory, stat 'upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/f1801892-ed57-47d9-bc57-f699f31ffaf8.ARW' immich-server-688c95f58d-bs56b immich-server Error: ENOENT: no such file or directory, stat 'upload/upload/63a658d3-c110-42e1-8621-7e345cfda737/f1801892-ed57-47d9-bc57-f699f31ffaf8.ARW' ``` A manual inspection of the filesystem shows the image was successfully moved, but the change was not persisted to the database. The image was supposed to be moved back, but wasn't. ```sh /usr/src/app $ find upload -name '_DSC4726*' upload/library/admin/2022/2022-11-23/_DSC4726.ARW /usr/src/app $ find upload -name '63a658d3-c110-42e1-8621-7e345cfda737/f1801892-ed57-47d9-bc57-f699f31ffaf8*' /usr/src/app $ ``` Loki shows there were some issues connecting to the database, which isn't Immich's fault but Immich should handle this better. ![image](https://github.com/immich-app/immich/assets/9749173/05f0e9d5-a933-4a3f-a1ab-890b9bee3613) ![image](https://github.com/immich-app/immich/assets/9749173/cedf4863-6f97-4b91-9ca5-8dc7d36eaf48) ### The OS that Immich Server is running on Kubernetes ### Version of Immich Server v1.61.1 ### Version of Immich Mobile App N/A ### Platform with the issue - [X] Server - [ ] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML N/A ``` ### Your .env content ```Shell N/A ``` ### Reproduction steps ```bash N/A ``` ### Additional information _No response_

OVERLORD added the 🗄️server label 2026-02-04 23:45:42 +03:00

OVERLORD closed this issue

2026-02-04 23:45:45 +03:00

OVERLORD commented

2026-02-04 23:45:49 +03:00

@uhthomas commented on GitHub (Jun 20, 2023):

Following some internal discussion on Discord, we believe it may be beneficial to queue asset migrations individually rather a single job which migrates all assets at once. This has some advantages:

Proper error handling per asset.
Individual asset migrations can be retried.
More consistent code, as all the other job queues behave this way.
Migrations sometimes take a long time (5+ minutes in my case).
Parallel job execution could be beneficial.

The current all-in-one migration will be marked as successful, even if some assets weren't moved correctly which isn't ideal.

@uhthomas commented on GitHub (Jun 20, 2023): Following some internal discussion on Discord, we believe it may be beneficial to queue asset migrations individually rather a single job which migrates all assets at once. This has some advantages: - Proper error handling per asset. - Individual asset migrations can be retried. - More consistent code, as all the other job queues behave this way. - Migrations sometimes take a long time (5+ minutes in my case). - Parallel job execution _could_ be beneficial. The current all-in-one migration will be marked as successful, even if some assets weren't moved correctly which isn't ideal.

OVERLORD commented

2026-02-04 23:45:55 +03:00

@uhthomas commented on GitHub (Jun 21, 2023):

Further, it looks like 163 files failed to move.

https://gist.github.com/uhthomas/650ff9f08f83f8f0ffb3008653df395d

@uhthomas commented on GitHub (Jun 21, 2023): Further, it looks like 163 files failed to move. https://gist.github.com/uhthomas/650ff9f08f83f8f0ffb3008653df395d

OVERLORD commented

2026-02-04 23:46:02 +03:00

@uhthomas commented on GitHub (Jun 21, 2023):

We had a long discussion about the right way to approach this and concluded the best thing to do in addition to individual jobs, is to move some logic into the database. We don't have specifics yet, but some psuedo code:

move asset

const dst = await calculateDestination(asset);
if (!checkFileExists(dst)) {
  await moveFile(src, dst);
}
await save({});

calculate destination

const tx = new Transaction(); // idk how this works with typeorm, this is how it works in Go
const results = tx.find({ dst });
if (!results.length) {
  tx.save({ dst });
  tx.commit();
  return;
}
tx.save({ dst, suffix: `-${results.length}` });
tx.commit();

This solution essentially moves the location of an asset from the existing asset table, to a new table and abstracts the location away. The schema of the table could look like:

CREATE TABLE asset_location (
  id SERIAL PRIMARY KEY,
  asset_id  INT,
  location VARCHAR(255) NOT NULL,
  suffix VARCHAR(255),
  CONSTRAINT fk_asset
      FOREIGN KEY(asset_id) 
	  REFERENCES assets(id)
);

@uhthomas commented on GitHub (Jun 21, 2023): We had a long discussion about the right way to approach this and concluded the best thing to do in addition to individual jobs, is to move some logic into the database. We don't have specifics yet, but some psuedo code: ###### move asset ```ts const dst = await calculateDestination(asset); if (!checkFileExists(dst)) { await moveFile(src, dst); } await save({}); ``` ###### calculate destination ```ts const tx = new Transaction(); // idk how this works with typeorm, this is how it works in Go const results = tx.find({ dst }); if (!results.length) { tx.save({ dst }); tx.commit(); return; } tx.save({ dst, suffix: `-${results.length}` }); tx.commit(); ``` --- This solution essentially moves the location of an asset from the existing asset table, to a new table and abstracts the location away. The schema of the table could look like: ```sql CREATE TABLE asset_location ( id SERIAL PRIMARY KEY, asset_id INT, location VARCHAR(255) NOT NULL, suffix VARCHAR(255), CONSTRAINT fk_asset FOREIGN KEY(asset_id) REFERENCES assets(id) ); ```

OVERLORD commented

2026-02-04 23:46:06 +03:00

@uhthomas commented on GitHub (Jun 21, 2023):

I wrote this script to move assets back to the right place.

https://gist.github.com/uhthomas/87cd39d0bbed044800a982556617f8db

@uhthomas commented on GitHub (Jun 21, 2023): I wrote this script to move assets back to the right place. https://gist.github.com/uhthomas/87cd39d0bbed044800a982556617f8db

OVERLORD commented

2026-02-04 23:46:09 +03:00

@uhthomas commented on GitHub (Jul 27, 2023):

So I've been thinking about this a bit and in addition to this, it would be really nice to support other file systems like S3. We can do this by dropping support for custom folders and switch to a flat hierarchy of unique directory names. Such <uuid>/<filename>. This is quite nice as upload destinations are guaranteed to be unique and do not require any move operations, and the original filename is preserved. In addition, this approach is fully compatible with S3. It would make the process a lot more simple and more reliable. The only potential issue I envision is that hundreds of thousands of objects in a single directory may not be compatible with most file systems. As such, it would probably have to work more similar to a tree with multiple directories to balance the number of files and distribute them evenly (a cryptographic random string would be fine).

@uhthomas commented on GitHub (Jul 27, 2023): So I've been thinking about this a bit and in addition to this, it would be really nice to support other file systems like S3. We can do this by dropping support for custom folders and switch to a flat hierarchy of unique directory names. Such `<uuid>/<filename>`. This is quite nice as upload destinations are guaranteed to be unique and do not require any move operations, and the original filename is preserved. In addition, this approach is fully compatible with S3. It would make the process a _lot_ more simple and more reliable. The only potential issue I envision is that hundreds of thousands of objects in a single directory may not be compatible with most file systems. As such, it would probably have to work more similar to a tree with multiple directories to balance the number of files and distribute them evenly (a cryptographic random string would be fine).

OVERLORD commented

2026-02-04 23:46:11 +03:00

@uhthomas commented on GitHub (Jul 27, 2023):

I'd also like to add that at current, Immich does not actually preserve the original filename if there are duplicate files on the same day. They are prefixed with a number, like ABC-1.jpg. The proposed solution would make this redundant and have the added benefit of not needing to mangle the original filename on disk.

@uhthomas commented on GitHub (Jul 27, 2023): I'd also like to add that at current, Immich _does not_ actually preserve the original filename if there are duplicate files on the same day. They are prefixed with a number, like `ABC-1.jpg`. The proposed solution would make this redundant and have the added benefit of not needing to mangle the original filename on disk.

OVERLORD commented

2026-02-04 23:46:14 +03:00

@bo0tzz commented on GitHub (Jul 27, 2023):

We used to do that and got a lot of pushback on it, which prompted the current custom folder support.

@bo0tzz commented on GitHub (Jul 27, 2023): We used to do that and got a lot of pushback on it, which prompted the current custom folder support.

OVERLORD commented

2026-02-04 23:46:20 +03:00

@uhthomas commented on GitHub (Jul 27, 2023):

We used to do that and got a lot of pushback on it, which prompted the current custom folder support.

Was the implementation identical, or was it slightly different? Links would be really helpful! I can understand pushback from files names <uuid> or <uuid>.jpg, but <uuid>/<filename>.jpg is a good compromise imo. I am afraid that if something doesn't change here, we won't be able to solve some of the issues we have with upload and storage reliability and support for S3 would be much more tricky.

@uhthomas commented on GitHub (Jul 27, 2023): > We used to do that and got a lot of pushback on it, which prompted the current custom folder support. Was the implementation identical, or was it slightly different? Links would be really helpful! I can understand pushback from files names `<uuid>` or `<uuid>.jpg`, but `<uuid>/<filename>.jpg` is a good compromise imo. I am afraid that if something doesn't change here, we won't be able to solve some of the issues we have with upload and storage reliability and support for S3 would be much more tricky.

OVERLORD commented

2026-02-04 23:46:26 +03:00

@alex-phillips commented on GitHub (Jul 27, 2023):

How would this potentially conflict with the recently added support for external / read-only assets? I imagine the database entry would simply refer to the filesystem location that doesn't match this proposed convention, though it may not matter if no filesystem operations are taking place against those assets.

@alex-phillips commented on GitHub (Jul 27, 2023): How would this potentially conflict with the recently added support for external / read-only assets? I imagine the database entry would simply refer to the filesystem location that doesn't match this proposed convention, though it may not matter if no filesystem operations are taking place against those assets.

OVERLORD commented

2026-02-04 23:46:29 +03:00

@bo0tzz commented on GitHub (Jul 27, 2023):

I don't see an issue with S3 support - we don't need to use the same scheme on every storage backend, so we can just take this approach only for S3 if we need.

#1098 is the PR that added storage templating, it has some (scattered) links to relevant issues/discussions.

@bo0tzz commented on GitHub (Jul 27, 2023): I don't see an issue with S3 support - we don't need to use the same scheme on every storage backend, so we can just take this approach only for S3 if we need. #1098 is the PR that added storage templating, it has some (scattered) links to relevant issues/discussions.

OVERLORD commented

2026-02-04 23:46:31 +03:00

@uhthomas commented on GitHub (Jul 27, 2023):

Thanks for the links @bo0tzz, definitely helpful for gathering context.

I think that diverging too much with different implementations will make things difficult. Whether it's because of the technical implementation like where file are initially uploaded and then what happens when the file upload is complete, or whether it's because storage migrations and this custom folder structure just wouldn't work with something like S3. It's probably wise to keep behaviour as similar as possible to avoid bugs and maintenance overhead, the only real way to do that imo is to work with the lowest common denominator where S3 does not support a move operation.

How would this potentially conflict with the recently added support for external / read-only assets? I imagine the database entry would simply refer to the filesystem location that doesn't match this proposed convention, though it may not matter if no filesystem operations are taking place against those assets.

If designed correctly, it shouldn't conflict at all. Ideally, it would actually make it easier as there would be more effort put into a proper abstraction for file systems.

@uhthomas commented on GitHub (Jul 27, 2023): Thanks for the links @bo0tzz, definitely helpful for gathering context. I think that diverging too much with different implementations will make things difficult. Whether it's because of the technical implementation like where file are initially uploaded and then what happens when the file upload is complete, or whether it's because storage migrations and this custom folder structure just wouldn't work with something like S3. It's probably wise to keep behaviour as similar as possible to avoid bugs and maintenance overhead, the only real way to do that imo is to work with the lowest common denominator where S3 does not support a move operation. > How would this potentially conflict with the recently added support for external / read-only assets? I imagine the database entry would simply refer to the filesystem location that doesn't match this proposed convention, though it may not matter if no filesystem operations are taking place against those assets. If designed correctly, it shouldn't conflict at all. Ideally, it would actually make it easier as there would be more effort put into a proper abstraction for file systems.

OVERLORD commented

2026-02-04 23:46:36 +03:00

@alex-phillips commented on GitHub (Jul 27, 2023):

I would have some concern with moving away from an available feature like storage template for a software-specific implementation of managing this type of personal media. I know that Immich came from managing the filesystem structure in the past, but moving back to that makes this type of media highly inaccessible except from within the app itself. Especially in its current state where Immich doesn't (and arguably shouldn't?) fill every role of interacting with these types of files.

Example scenario: Immich is used for asset backup from devices, browsing, sharing, etc. But current metadata management and photo editing is not possible in Immich. Moving the filesystem structure to something that is not human friendly makes interacting with and using these assets extremely difficult to navigate.

@alex-phillips commented on GitHub (Jul 27, 2023): I would have some concern with moving away from an available feature like storage template for a software-specific implementation of managing this type of personal media. I know that Immich came from managing the filesystem structure in the past, but moving back to that makes this type of media highly inaccessible except from within the app itself. Especially in its current state where Immich doesn't (and arguably shouldn't?) fill every role of interacting with these types of files. Example scenario: Immich is used for asset backup from devices, browsing, sharing, etc. But current metadata management and photo editing is not possible in Immich. Moving the filesystem structure to something that is not human friendly makes interacting with and using these assets extremely difficult to navigate.

OVERLORD commented

2026-02-04 23:46:40 +03:00

@uhthomas commented on GitHub (Jul 27, 2023):

I appreciate and understand that perspective, I can definitely see how a bunch of randomly generated directory names would be hard to work with, regardless of whether or not the original filename is preserved. There is a middle-ground, where immich could persist uploaded items to directories created with the current date, like 2022/12/12/<uuid>/<filename>.jpg but this clearly still isn't ideal.

I think we have to come to some sort of conclusion on what we do or don't want to support. I am not sure it's possible to have our cake and eat it too. Either we design Immich to be reliable and scalable without regard for some features, or the existing behaviour is preserved with the caveat of disparate storage implementations, complexity and issues like this one.

With respect to one point, I think that if Immich is a backup solution, then users should not be editing their files directly.

Further thinking, given the read-only feature, I think that may be a good way to sort of support both at once? The files uploaded to Immich can be in any form they need to be, whereas files that users may want to work with locally can be part of that read-only directory.

Would be really interested to hear your further thoughts.

@uhthomas commented on GitHub (Jul 27, 2023): I appreciate and understand that perspective, I can definitely see how a bunch of randomly generated directory names would be hard to work with, regardless of whether or not the original filename is preserved. There is a middle-ground, where immich could persist uploaded items to directories created with the current date, like `2022/12/12/<uuid>/<filename>.jpg` but this clearly still isn't ideal. I think we have to come to some sort of conclusion on what we do or don't want to support. I am not sure it's possible to have our cake and eat it too. Either we design Immich to be reliable and scalable without regard for some features, or the existing behaviour is preserved with the caveat of disparate storage implementations, complexity and issues like this one. With respect to one point, I think that if Immich is a backup solution, then users _should not_ be editing their files directly. Further thinking, given the read-only feature, I think that may be a good way to sort of support both at once? The files uploaded to Immich can be in any form they need to be, whereas files that users may want to work with locally can be part of that read-only directory. Would be really interested to hear your further thoughts.

OVERLORD commented

2026-02-04 23:46:46 +03:00

@etnoy commented on GitHub (Jul 28, 2023):

For read only files and upcoming external libraries, that's not an issue with this proposal. They just stay put where they happened to be, the db points to their filename, and that's it. I think this only relates to uploaded (i.e. internal) assets

@etnoy commented on GitHub (Jul 28, 2023): For read only files and upcoming external libraries, that's not an issue with this proposal. They just stay put where they happened to be, the db points to their filename, and that's it. I think this only relates to uploaded (i.e. internal) assets

OVERLORD commented

2026-02-04 23:46:49 +03:00

@jrasm91 commented on GitHub (Oct 11, 2023):

@uhthomas why did you reopen this?

@jrasm91 commented on GitHub (Oct 11, 2023): @uhthomas why did you reopen this?

OVERLORD commented

2026-02-04 23:46:55 +03:00

@uhthomas commented on GitHub (Oct 11, 2023):

Closing for https://github.com/immich-app/immich/issues/4442 and https://github.com/immich-app/immich/issues/4445.

@uhthomas commented on GitHub (Oct 11, 2023): Closing for https://github.com/immich-app/immich/issues/4442 and https://github.com/immich-app/immich/issues/4445.

OVERLORD referenced this issue

2026-02-05 13:54:21 +03:00

[PR #978] [MERGED] chore(server) refactor serveFile and downloadFile endpoint #8852

Sign in to join this conversation.

Branches Tags

main

fix/warn-invalid-filetype

update-pwa

chore/translations

release/next

refactor/star-rating

renovate/flutter

renovate/major-machine-learning

uhthomas/feat-sort-smart-search

renovate/github-cqlabs-homebrew-dcm-1.x

push-vxwxqoulmxun

push-zlzxxyywnmtr

feat/mobile-edit-2-server-sync-entity

chore/deduplicate-storage-template-example

feat/splash-screen-error

fix/download-button

fix/maintenance-reload

feat/video-player

feat/mobile-editing

feat/use-native-clients

refactor/remove-replace-with-upload

push-snrprxmlposz

push-okmnxsumoyzr

uhthomas/chore-mobile-maplibre

feat/library-offline-stats

uhthomas/mobile-fix-asset-details-album-pop

feat/crawl-wrapper

feat/open-in-browser

push-skvzqoozqkpl

feat/custom-date-range

feat/edit-filters

fix/locale-settings-desc

push-xyozownmuwqp

push-lvyturrtwkrq

push-mvnsqpxklmnu

push-ztrmyrpuwvow

push-rsywxvptwxuv

push-pvvtwywwqzvy

postgres-socketio

feat/pg-queue

proposal/zod

refactor/asset-upload

feat/integrity-checks-izzy

renovate/connectivity_plus-7.x

better-project-structure

uhthomas/mobile-feat-asset-viewer-details

fix/ml-rocm-build

fix/25803

feat/asset-file-apis

midzelis/wip

push-zpwsovysllvn

push-nwxlpmyzkyrl

feature/bottom-buttons-order

sqlite_thumbs

fix-keep-correct-ios-shared-album-asset

fix-memory-generation-and-display

push-vpxwmwwxwnvw

fix-migration-width-height

revert/prettier-translations

shared-deep-link-handler

feat/thumbnail-native-clients

feat/platform-clients

fix/foreground-cloud-sync

filter-by-person

feat/csp

refactor/sidebar

fix/disable-editing

fix/view-timeline-deeplink

image-zoom-on-slow-connection

fix-consider-dar-for-video-dimension

fix/merged-edited-assets

open-api-fix

feat/create-job-with-dto

use-toast-primary

feat/vitest-4

feat/ios-fastlane-match

match-signing

fix-update-time-update-timeline

feat/modal-routes

feat/panorama-tiles

feature/mobile-view-asset-owner

feat/system-settings

feature/show-activity-count

better-info-in-asset-viewer

fix/all-people-count

feat/location-favorites

feature/rearrange-buttons-2

fix/download-storage-template

feat/kb-shortcuts-mobile

fix/people-count

push-qolzzzzxrvvn

chore/originals-in-asset-files

feat/asset-size-columns

ben/tree-a11y

new-search-filter-ui

refactor/expectSelectedReadonly

refactor/mobile-grdb

push-qvuktpxmkknu

feat/mobile-native-local-sync

refactor/timeline_ops

fix/scrubber_end

feat/version.txt

feat/context-menus

feat/server-chunked-uploads

refactor/virtualsegment

refactor/rename_daymonth_groups

fix/restrict-android-bg-worker

feat/android-periodic-worker

fix-remote-sync-clean-up

refactor/timeline_move_ops

fix/timeline_split_selectable

feat/keyboard_actions_help_modal

feat/static_frontend

feat/notification-warnign-android

feat/plugins2

feat/plugins

test/create-workflow-token-action

fix/docs-force

debug/search-result-similarity

debug/cf-chunked-uploads

feat/eslint_rule

feat/search-filter-album/web

refactor/timeline_photostream

refactor/timelineasset_asset

feat/session-permissions

feat/timeline_photostream_assetnav

feat/timeline_minor_optimize

feat/timeline_perf_nocomp

feat/timeline_search_results_actions

feat/timeline_search_results_page

fix/timeline_padding

fix/timeline_search_reactivity_warnings

feat/timeline_scrollbar

feat/timeline_stream_withviewer

fix/timeline_back_forth_nav

refactor/timeline_photostream_component

fix/generated-files-checks

fix/locate-button-local

chore/base-image-mimalloc

refactor/timeline_assetlayout

refactor/timeline_selectable

refactor/timeline_aware_actions

refactor/timeline_monthsegment

feat/remove-old-pages

chore/deps-gradle

tmp_photostream

tmp/lcms

feat/mobile-dynamic-thumbnails

fix/mobile-finer-thumbnail-concurrency

refactor/timeline1

refactor/extract_photostream

refactor/rename_load_api

refactor/timeline2

refactor/timeline3

feat/multi-select-asset-viewer

feat-no-thumbhash-cache

refactor/asset_grid

feat/faster-access-checks

fix/18991

fix/19543

chore/temp-remove

fix/21419

feat/mobile-hdr-images

chore/update-mise-lockfile

feat/mise-server-checks

feat/mise-ci

feat/windows-2025

feat/dev_cli

refactor/mobile-migrate-clients

fix/map-theme

fix/require-checkbox

chore/use_swc

feat/efficient-thumbnail-decoding

refactor/mobile-thumbhash

refactor/mobile-thumbhash-new

feat/beta-background-upload

fix/beta-timeline-memories-setting

fix/failed-uploads-not-removed

feat/mobile-shared-album

feat/groups

drift-map-page

drift-auth-user-sync

fix/disable-memory

feat/add-to-album-action

edit-date-time-action

drift-people-page

sqlite-remove-isIn

chore/required-reviewers

refact/asset-manager

fix/folder-sort

pnpm

feat/widget-multiple-server-urls

chore/medium-tests-dbname

fix/web-no-iterator-find

fix/map-pan-interruption

track-livephotos

timeline_events

chore/oxlint-migration

feat/maintenance-worker

feat/dav

chore/demo-snapshot

refactor/server-side-dedupe

feat/integrity-checks

dev/recognition-eval

lighter_buckets_test

perf/postgres-queue

postgres-queue

focus_rings

refactor/web-stores-1

refactor/add-to-taken

feat/sort-places

vet

tmp/demo-snapshot-preview

fix/server-migration-file-extension

fix/asset-update-race-condition

rknn-toolkit-lite2

refactor/mobile-split-up-search-page

feature/Add-rocm-support-for-machine-learning

feat/rocm

chore/async-hash-file

feat/shared-link-view-count

feat/rotation

feat/graphql

feat/job-ids

feat/ignore-library-permission-error

feat/docker-compose-builder

feat/kysely-typeorm

mobile/onboarding

no-video-player

fix/server-qsv-output-format

chore/server-geodata-tweaks

mobile/native-video-player-no-hero

feat/xxhash

fix/docs-concurrency

feat/local-tileserver

refactor/exif-orientation

original-path-infix

refactor/mobile/login-form-1

feat/server-editor-endpoints

fix/server-qsv-vbr

fix-mobile-db-problems

feat/ml-armnn-conversion

feat/mobile/backup-with-album-info

feat/fast-initial-sync-1

chore/handle-output_dims

feat/unassign-faces

feat/shortcuts-on-asset-grid

feat/capacitor-mobile-app-poc

feat/server-nvenc-hw-decoding

fix/mobile-fetch-non-archive

web/automation-ui

feat/mobile-server-endpoint-save-dropdown

object-storage

feat/memories-animations

dev/metrics

ml/tflite

feat/ml-export-cli

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: immich-app/immich#978