Folders: Allow reserved characters in original names to be indexed #2137

Open
opened 2026-02-20 01:06:54 -05:00 by deekerman · 3 comments
Owner

Originally created by @kezon on GitHub (Jul 8, 2024).

1. What is not working as documented?

Photoprism is an amazing project. I started using it few weeks ago and I use my originals structure where each folder contains a country code, pipe and location and description.
Like this:

CZ | Prague, Wedding

I have scanned and indexed 10000+ images, everything works just great, I can see search, people, locations everything... except browning folders and originals.

Whenever I want to brows to any of a folder which contains the pipe | character, I get an empty folder message:
"No pictures found"

In logs I can see:

Error
July 8, 2024 at 8:07:56 AM GMT+2
folder: open /photoprism/originals/2017/06/CZ Praha, ECH: no such file or directory

Becasue the real path is not
/photoprism/originals/2017/06/CZ Praha, ECH
but
/photoprism/originals/2017/06/CZ | Praha, ECH

2. How can we reproduce it?

  1. Create any folder in originals and use a pipe character | in the folder name
  2. Let it be indexed
  3. Check in search that the images can be seen, opened
  4. Browse to Library, Originals, particular folder created in step (1)
  5. Get a message "no pictures found"
  6. Browse to Folder, particular folder created in step (1)
  7. Get a message "no pictures found"
  8. Check logs, read a message: 2024-07-08 08:24:43 ERRO folder: open /photoprism/originals/2017/05/CZ Praha, ECH: no such file or directory

3. What behavior do you expect?

As with any other standard character, the pipe should not be left out from the path name

4. What could be the cause of your problem?

my guess is that the pipe is expected to be used for some other purpose and thus ignored

5. Can you provide us with example files for testing, error logs, or screenshots?

I can provide any log, but it seems rather simple to reproduce

6. Which software versions do you use?

(a) PhotoPrism Architecture & Build Number: AMD64 [PhotoPrism® CE] Build [240531-60b3a4628](
(b) Database Type & Version: MariaDB
(c) Operating System Types & Versions: Linux Debian 12, 6.1.0-22-amd64
(d) Browser Types & Versions: Firefox, Chrome, Safari on Mac
(e) Installed as a docker container (Docker version 27.0.3, build 7d4bcd8), image: mariadb:11, image: photoprism/photoprism:latest
(f) originals mapped on NFS share from TrueNas into /mnt/nas/Originals which is then linked to a container into Originals

volumes:
- "/mnt/nas/Originals:/photoprism/originals" # Original media files (DO NOT REMOVE)
- "./storage:/photoprism/storage" # Writable storage folder for cache, database, and sidecar files (DO NOT REMOVE)
-

7. On what kind of device is PhotoPrism installed?

The Phototropism runs on a Intel NUC 12th generation
(a) Device / Processor Type: Intel Core i3
(b) Physical Memory & Swap Space: 8 GB
(c) Storage Type: SSD nVMe 1TB, 950 GB free

8. Do you use a Reverse Proxy, Firewall, VPN, or CDN?

The docker is accessible both locally over http at port 80 and also over HA proxy on a router pfsense. same behavior regardless how it is accessed

Originally created by @kezon on GitHub (Jul 8, 2024). #### 1. What is not working as documented? Photoprism is an amazing project. I started using it few weeks ago and I use my originals structure where each folder contains a country code, pipe and location and description. Like this: CZ | Prague, Wedding I have scanned and indexed 10000+ images, everything works just great, I can see search, people, locations everything... except browning folders and originals. Whenever I want to brows to any of a folder which contains the pipe | character, I get an empty folder message: "No pictures found" In logs I can see: Error July 8, 2024 at 8:07:56 AM GMT+2 folder: open /photoprism/originals/2017/06/CZ Praha, ECH: no such file or directory Becasue the real path is not /photoprism/originals/2017/06/CZ Praha, ECH but /photoprism/originals/2017/06/CZ | Praha, ECH #### 2. How can we reproduce it? 1. Create any folder in originals and use a pipe character | in the folder name 2. Let it be indexed 3. Check in search that the images can be seen, opened 4. Browse to Library, Originals, particular folder created in step (1) 5. Get a message "no pictures found" 6. Browse to Folder, particular folder created in step (1) 7. Get a message "no pictures found" 8. Check logs, read a message: 2024-07-08 08:24:43 ERRO folder: open /photoprism/originals/2017/05/CZ Praha, ECH: no such file or directory #### 3. What behavior do you expect? As with any other standard character, the pipe should not be left out from the path name #### 4. What could be the cause of your problem? my guess is that the pipe is expected to be used for some other purpose and thus ignored #### 5. Can you provide us with example files for testing, error logs, or screenshots? I can provide any log, but it seems rather simple to reproduce #### 6. Which software versions do you use? (a) PhotoPrism Architecture & Build Number: AMD64 [PhotoPrism® CE] Build [240531-60b3a4628]( (b) Database Type & Version: MariaDB (c) Operating System Types & Versions: Linux Debian 12, 6.1.0-22-amd64 (d) Browser Types & Versions: Firefox, Chrome, Safari on Mac (e) Installed as a docker container (Docker version 27.0.3, build 7d4bcd8), image: mariadb:11, image: photoprism/photoprism:latest (f) originals mapped on NFS share from TrueNas into /mnt/nas/Originals which is then linked to a container into Originals volumes: - "/mnt/nas/Originals:/photoprism/originals" # Original media files (DO NOT REMOVE) - "./storage:/photoprism/storage" # *Writable* storage folder for cache, database, and sidecar files (DO NOT REMOVE) - #### 7. On what kind of device is PhotoPrism installed? The Phototropism runs on a Intel NUC 12th generation (a) Device / Processor Type: Intel Core i3 (b) Physical Memory & Swap Space: 8 GB (c) Storage Type: SSD nVMe 1TB, 950 GB free #### 8. Do you use a Reverse Proxy, Firewall, VPN, or CDN? The docker is accessible both locally over http at port 80 and also over HA proxy on a router pfsense. same behavior regardless how it is accessed
Author
Owner

@lastzero commented on GitHub (Jul 8, 2024):

The following reserved characters, e.g. in Windows or WebDAV, are currently ignored in file and folder names:

  • < (less than)
  • > (greater than)
  • : (colon)
  • " (double quote)
  • / (forward slash)
  • \ (backslash)
  • | (vertical bar or pipe)
  • ? (question mark)
  • * (asterisk)

While other file systems, e.g. on Linux, allow some of these characters to be used (if they are properly escaped...), we currently do not have a file system detection implemented with different handling depending on the type. It may be possible to work around this by allowing additional characters in folder names to be indexed. However, this could lead to problems elsewhere, e.g. when creating download file names that must not contain reserved characters so that they can be saved/used on all operating systems.

You can find the corresponding code in the pkg/cleanup package, so you can verify that it is intentional and not a bug (although the error handling in the application and the related documentation could probably be improved to make it more obvious):
github.com/photoprism/photoprism@22aa700b1e/pkg/clean/filename.go (L8-L26)

Removing all checks and allowing everything is not an option, as this would significantly increase the attack surface.

@lastzero commented on GitHub (Jul 8, 2024): The following reserved characters, e.g. in [Windows](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file) or WebDAV, are currently ignored in file and folder names: - `<` (less than) - `>` (greater than) - `:` (colon) - `"` (double quote) - `/` (forward slash) - `\` (backslash) - `|` (vertical bar or pipe) - `?` (question mark) - `*` (asterisk) While other file systems, e.g. on Linux, allow some of these characters to be used (if they are properly escaped...), we currently do not have a file system detection implemented with different handling depending on the type. It may be possible to work around this by allowing additional characters in folder names to be indexed. However, this could lead to problems elsewhere, e.g. when creating download file names that must not contain reserved characters so that they can be saved/used on all operating systems. You can find the corresponding code in the `pkg/cleanup` package, so you can verify that it is intentional and not a bug (although the error handling in the application and the related documentation could probably be improved to make it more obvious): https://github.com/photoprism/photoprism/blob/22aa700b1ec228d1f54f11a4e631aa9656383fda/pkg/clean/filename.go#L8-L26 Removing all checks and allowing everything is not an option, as this would significantly increase the attack surface.
Author
Owner

@lastzero commented on GitHub (Jul 8, 2024):

A possible solution could be to have the original name as an additional field alongside the sanitized name so that the original folder can be found by this name. The sanitized name would then still be used for creating sidecar folders and download file/archive names.

@lastzero commented on GitHub (Jul 8, 2024): A possible solution could be to have the original name as an additional field alongside the sanitized name so that the original folder can be found by this name. The sanitized name would then still be used for creating sidecar folders and download file/archive names.
Author
Owner
@lastzero commented on GitHub (Jul 8, 2024): Related Issues: - https://github.com/photoprism/photoprism/issues/3669 - https://github.com/photoprism/photoprism/issues/3695
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/photoprism#2137
No description provided.