Having a comma in a path added to external library breaks scanning

[erikthegamer1242]

The bug

When having multiple paths that have commas in them added to an external library breaks the library and it can't access any assets.

For example, I have an External library named test1:

• I have added a path /projects/2024/06/cars/export
• This library works

The second example I have an External library named test2:

• I have added a path /projects/2024/06/cars/export, 28.6.2024
• This library works

Third example I have an External library named test3:

• I have added multiple paths:
  • /projects/2024/06/red-cars/export, 28.6.2024
  • /projects/2024/06/white-cars/export, 28.6.2024
• This library won't find any assets because I have more than one path with a comma. I would have to guess that somewhere in the backend something gets split by commas.

For the record, I have been using commas in folders for a long time and it is not an OS issue.

The OS that Immich Server is running on

Docker 20.10.24, Docker Compose v2.21.0, Unraid 6.12.3 (kernal 6.1.38-Unraid )

Version of Immich Server

v1.106.2

Version of Immich Mobile App

N/A

Platform with the issue

• [X] Server
• [ ] Web
• [ ] Mobile

Your docker-compose.yml content

I don't have one

Your .env content

I don't have one

Reproduction steps

1. Add a new external library
2. Somewhere on the filesystem create two or more folders containing commas (for example test,1 and test,2)
3. Add *each* folder separately to the *same* external library 
4. Watch how the external library won't detect any assets

Relevant log output

[Nest] 200  - 06/29/2024, 8:49:14 AM   DEBUG [Microservices:LibraryService] Found 0 asset(s) when crawling import paths /projects/2024/06/28.6.2024, Export

Additional information

No response

[alextran1502]

This is not the common practice of naming folders and paths. I highly suggest moving away from this practice because, eventually, you will run into issues with different software.

[fscheps]

I also had a lot of trouble with spaces on my long paths. Ended up changing the paths, but this broke everything and had to install Immich from scratch again.

[mschiff]

I am having the same issue. Scanning is broken for paths containing a comma (","). This is clearly a bug in immich. Please dont argue that having a totally valid character in the path should be avoided or make it clear, that Immich does not support valid paths on Linux and only accepts a small subset with only a limited number of characters.

On Linux a path can contain almost any character. Only the forward slash (/) and the NUL bytes is not possible.

[gschintgen]

Yes, this clearly is a bug. Photo collections are often managed using multiple different tools and often enough it's easiest to "encode" album names as folders. As such they are often treated as plain unicode text, including spaces, commas, parentheses, ampersands, accented characters, asian glyphs, etc.

None of this is unreasonable. Those names are not supposed to be 1970-style basic file names like in etc or usr (which I much appreciate for their easy handling BTW)

It's not Windows either... ;-)

[etnoy]

Thanks for the report, I'll look into this

[etnoy]

Can confirm this bug. We do a brace expansion in the asGlob method of the storage repository. I'll have to figure out a way to solve this issue. Another way to trigger this bug is to have a brace like { or } in a path when having 2 or more import paths.