fix(server): support special characters in library paths

[sushain97]

Directories with special characters, like (, aren't properly crawled. This is fixed by escaping the provided paths before they're passed to fast-glob. My newly added test now passes. But, another test that uses * had to be deleted since we can't treat input paths as patterns and verbatim at the same time. I audited the use cases and it seems like only actual paths would be passed (please double check!). In particular, library paths are validated as real paths before being crawled.

If this behavior is intentional, the docs/UI should probably clarify that users need to escape special characters themselves. The path validation logic would also need to be tweaked to 'unescape' before checking the path. That seems a bit confusing.

cc @jrasm91 since you recently touched this and have last blame on the test that I deleted :)

[sushain97]

This code feels a bit redundant since Array.join should work fine on a singleton array. I just left it as is but can tweak.

[sushain97]

@danieldietzler thanks for the review! would it be possible to get this merged before the next release?

[jrasm91]

I would prefer to just add a note to the docs explaining how to escape special characters, rather than removing the "glob-matching" feature altogether for every user.

[sushain97]

@jrasm91 I don't think that feature really works since invalid paths are rejected:

immich/server/src/services/library.service.ts

Line 315 in 540e568

const stat = await this.storageRepository.stat(importPath);

.

I'd argue the current behavior is a regression rather than a feature :) External libraries with ( used to work and now all their assets are marked offline.

[jrasm91]

Oh, I see. Maybe it does make more sense then for the import paths to just point to an existing folder (no glob syntax) and only the exclude paths use special characters (glob syntax).

[sushain97]

Oh, I see. Maybe it does make more sense then for the import paths to just point to an existing folder (no glob syntax) and only the exclude paths use special characters (glob syntax).

That seems like reasonable behavior and this PR will preserve it since the exclusion patterns are still passed to fast-glob verbatim.

I could see a future feature that lets you use globs on an per path opt-in basis. Not sure it'd be a common ask, though.