[synchronization] Sync fail with files containing ' (apostrophe) in filename #250

New Issue

2026-10-04T23:49:02+02:00

adam commented

2026-10-04 23:49:02 +02:00

Reported by JanisV on 23 Jan 2014 11:06

Version: 2.6.0

Sync any folder with file "Kamen' at Nameless.JPG" and $conf['sync_chars_regex'] = '/.*/'; fail with:
Warning: [mysql error 1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'at Nameless.JPG','Kamen' at Nameless','2014-01-22 23:45:16','./galleries/Photo/' at line 11555

Additional information: piwigo/admin/site_update.php:512 use filename without pwg_db_real_escape_string, like in piwigo/admin/include/functions_upload.inc.php:354

Piwigo Bugtracker #3030

**Reported by JanisV on 23 Jan 2014 11:06** **Version:** 2.6.0 Sync any folder with file "Kamen' at Nameless.JPG" and $conf['sync_chars_regex'] = '/.*/'; fail with: Warning: [mysql error 1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'at Nameless.JPG','Kamen' at Nameless','2014-01-22 23:45:16','./galleries/Photo/' at line 11555 **Additional information:** piwigo/admin/site_update.php:512 use filename without pwg_db_real_escape_string, like in piwigo/admin/include/functions_upload.inc.php:354 [Piwigo Bugtracker #3030](http://piwigo.org/bugs/view.php?id=3030)

adam closed this issue

2026-10-04 23:49:02 +02:00

adam commented

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

Comment posted by JanisV on 23 Jan 2014 11:13

Related issue #2971

**Comment posted by JanisV on 23 Jan 2014 11:13** Related issue #2971

adam commented

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

Comment posted by bryanw on 25 Sep 2014 20:47

It is crashing because you modified the regex from the default. Set it back to the default value of: /^[a-zA-Z0-9-_.]+$/

That is, the system only accepts a range of the English a-z and A-Z, the numbers 0-9, the underscore, the single dash, and the dot/period. No other characters are allowed. No spaces. No accents like é. No slashes (forward or back). No symbols. Using them can cause the app to crash or the database to become corrupt or other bad things to happen.

Unfortunately bad handling of input is pervasive through the Piwigo code.

Apostrophe, accented characters, slashes, and many other characters cause serious problems and the dev team does not want to devote the resources to rewrite large segments of the code. Remember it is a small team of volunteers.

In addition to file names it also impacts email addresses, user comments, metadata, and more.

Since the dev team is small I've looked into fixing it and posting a patch (I'm a programmer by day) but the extent of the change is huge. It impacts almost every part of the program. Nearly everything in the system touches the database, and nearly all of the database code improperly handles queries. It is not a simple bug fix, but a near-complete rewrite of the entire database interface.

From a correctness point of view this is a serious bug. Any character should be valid. Any file name supported by the filesystem should be valid. Any character allowed by the RFC should be valid for email. Special characters that are exposed as URLs can be escaped, and those accepted from forms can be properly handled and sanitized. Sadly the code does not properly handle user input and file names as distinct objects, but mixes it in with other code.

**Comment posted by bryanw on 25 Sep 2014 20:47** It is crashing because you modified the regex from the default. Set it back to the default value of: /^[a-zA-Z0-9-_.]+$/ That is, the system only accepts a range of the English a-z and A-Z, the numbers 0-9, the underscore, the single dash, and the dot/period. No other characters are allowed. No spaces. No accents like é. No slashes (forward or back). No symbols. Using them can cause the app to crash or the database to become corrupt or other bad things to happen. Unfortunately bad handling of input is pervasive through the Piwigo code. Apostrophe, accented characters, slashes, and many other characters cause serious problems and the dev team does not want to devote the resources to rewrite large segments of the code. Remember it is a small team of volunteers. In addition to file names it also impacts email addresses, user comments, metadata, and more. Since the dev team is small I've looked into fixing it and posting a patch (I'm a programmer by day) but the extent of the change is huge. It impacts almost every part of the program. Nearly everything in the system touches the database, and nearly all of the database code improperly handles queries. It is not a simple bug fix, but a near-complete rewrite of the entire database interface. From a correctness point of view this is a serious bug. Any character should be valid. Any file name supported by the filesystem should be valid. Any character allowed by the RFC should be valid for email. Special characters that are exposed as URLs can be escaped, and those accepted from forms can be properly handled and sanitized. Sadly the code does not properly handle user input and file names as distinct objects, but mixes it in with other code.

adam commented

2026-10-04 23:49:04 +02:00

Comment posted by plg on 1 Oct 2014 14:41

At the beginning, we have set restrictions on file/directory names for synchronization. The rest of the code was relying on these restrictions and we can't say it's a bug to consider there is no quote in file path. Then, under heavy pressure :-), we have added a configuration parameter so that webmasters can extend the authorized characters. Now someone found that using a specific character breaks some piece of code. I'm sorry but I don't think it's prioritary to be compatible with any character.

By the way, appart from synchronization, if you use any other method, there is no problem with quotes or chinese character or whatever. The problem is only for synchronization. I don't know if it really worth it to make sync compatible with "any" character.

The bugtracker is not the right place for "discussions". The forum is the better place :-)

**Comment posted by plg on 1 Oct 2014 14:41** At the beginning, we have set restrictions on file/directory names for synchronization. The rest of the code was relying on these restrictions and we can't say it's a bug to consider there is no quote in file path. Then, under heavy pressure :-), we have added a configuration parameter so that webmasters can extend the authorized characters. Now someone found that using a specific character breaks some piece of code. I'm sorry but I don't think it's prioritary to be compatible with any character. By the way, appart from synchronization, if you use any other method, there is no problem with quotes or chinese character or whatever. The problem is only for synchronization. I don't know if it really worth it to make sync compatible with "any" character. The bugtracker is not the right place for "discussions". The forum is the better place :-)

adam commented

2026-10-04 23:49:05 +02:00

Comment posted by bryanw on 1 Oct 2014 18:58

You're right, as you have replied to quite a few forum comments discounting the bug. Yes, the developers have known about the issue for at least 11 years (e.g. http://piwigo.org/forum/viewtopic.php?id=957 is probably the oldest) the issue is all over the forums, especially the French forums where I see about 400 threads on the topic. Several of them declared it was a fatal flaw and they would look at other products.

As I wrote, I have looked through the code and agree that it is a massive change. I don't envy the dev team on how they intend to fix it.

For it not affecting other systems or being common in the code, a quick search of the bug database disagrees: #581 #618 #1366 #2064 #2282 #2419 and many more.

In my view (as a full-time developer) it is a serious bug that valid file names are not permitted during file synchronization. Valid names on the OS should be valid names for ingest to the app. Even if the app renames them internally, the file names are legal according to the OS and should be synchronized.

**Comment posted by bryanw on 1 Oct 2014 18:58** You're right, as you have replied to quite a few forum comments discounting the bug. Yes, the developers have known about the issue for at least 11 years (e.g. http://piwigo.org/forum/viewtopic.php?id=957 is probably the oldest) the issue is all over the forums, especially the French forums where I see about 400 threads on the topic. Several of them declared it was a fatal flaw and they would look at other products. As I wrote, I have looked through the code and agree that it is a massive change. I don't envy the dev team on how they intend to fix it. For it not affecting other systems or being common in the code, a quick search of the bug database disagrees: #581 #618 #1366 #2064 #2282 #2419 and many more. In my view (as a full-time developer) it is a serious bug that valid file names are not permitted during file synchronization. Valid names on the OS should be valid names for ingest to the app. Even if the app renames them internally, the file names are legal according to the OS and should be synchronized.

adam commented

2026-10-04 23:49:06 +02:00

Has this gone anywhere yet?

I just installed Piwigo 2.9.4 because it seemed like a good match for the image collection on my NAS. Out of 1,225 files, synchronize accepted 18. The rest was rejected for the crime of containing underlines, dots and braces (whitespace, too, maybe?).

rm -r'd this for now and trying my luck with lychee or something else, but apart from its pickiness on filenames, Piwigo looked really nice. Would definitely give it another try once this issue is resolved.

Has this gone anywhere yet? I just installed Piwigo 2.9.4 because it seemed like a good match for the image collection on my NAS. Out of 1,225 files, synchronize accepted 18. The rest was rejected for the crime of containing underlines, dots and braces (whitespace, too, maybe?). rm -r'd this for now and trying my luck with lychee or something else, but apart from its pickiness on filenames, Piwigo looked really nice. Would definitely give it another try once this issue is resolved.

adam commented

2026-10-04 23:49:07 +02:00

Same here. I'm battling through various photo gallery solutions and Piwigo would be the only one up to now that does what I want, except for this one flaw that is a deal breaker.

Same here. I'm battling through various photo gallery solutions and Piwigo would be the only one up to now that does what I want, except for this one flaw that is a deal breaker.

adam commented

2026-10-04 23:49:07 +02:00

Same here, I was about to post an issue for this but found that one instead.
I was using a 2.5.2 version which I patched at the time to allow site synchronization with quotes in names.
I migrated to 2.9.5 and I had to redo my changes, which is really annoying.
Sure, I have changed the default regex for filenames, but I could not see any reason why I was not allowed to have single quotes in the filename.
So, could this finally be looked at seriously? I mean, French isn't the only language that uses apostrophes on a regular basis.

Same here, I was about to post an issue for this but found that one instead. I was using a 2.5.2 version which I patched at the time to allow site synchronization with quotes in names. I migrated to 2.9.5 and I had to redo my changes, which is really annoying. Sure, I have changed the default regex for filenames, but I could not see any reason why I was not allowed to have single quotes in the filename. So, could this finally be looked at seriously? I mean, French isn't the only language that uses apostrophes on a regular basis.

adam commented

2026-10-04 23:49:08 +02:00

I've made some tests today and here are my thoughts about this everlasting issue:

the "add photos with synchronization" is our old way to do things. It is still available and maintained "as is" but 99.99% of new users are using the upload form or a remote tool to add photos, since ~2009. It explains why I personnaly don't want to give much time/energy on this feature.
the Piwigo Remote Sync app should be a solution to these characters restrictions. First task for @voriondev (starting tomorrow) will be check this.
I've made some small pwg_db_real_escape_string on admin/site_update which allow inserting file names including special characters. Sync "works", but after that i.php is not able to get the whole file path. To make things complicated I have added a & in the file name ($_SERVER['QUERY_STRING'] does not give us the whole path, breaking the derivatives generator...). I think the only "clean" way to fix this would be to have an original file name stored in the database (just like we have for API uploaded photos) and a "safe" path to give to i.php, without renaming file in the file system and without modifying the whole Piwigo code. I clearly don't want to work on it. If @modus75 or @samwilson are interested, I'm OK to help with some tests, but not much more :-/

I've made some tests today and here are my thoughts about this everlasting issue: - the "add photos with synchronization" is our old way to do things. It is still available and maintained "as is" but 99.99% of new users are using the upload form or a remote tool to add photos, since ~2009. It explains why I personnaly don't want to give much time/energy on this feature. - the Piwigo Remote Sync app should be a solution to these characters restrictions. First task for @voriondev (starting tomorrow) will be check this. - I've made some small pwg_db_real_escape_string on admin/site_update which allow inserting file names including special characters. Sync "works", but after that i.php is not able to get the whole file path. To make things complicated I have added a & in the file name (`$_SERVER['QUERY_STRING']` does not give us the whole path, breaking the derivatives generator...). I think the only "clean" way to fix this would be to have an original file name stored in the database (just like we have for API uploaded photos) and a "safe" path to give to `i.php`, without renaming file in the file system and without modifying the whole Piwigo code. I clearly don't want to work on it. If @modus75 or @samwilson are interested, I'm OK to help with some tests, but not much more :-/

adam commented

2026-10-04 23:49:09 +02:00

I have implemented the solution proposed by @obones in https://github.com/Piwigo/Piwigo/pull/598#issuecomment-496506502 by using pwg_db_real_escape_string in admin/site_update.php on fields {file, name, path}.

I know it won't work for some exotic characters such as "&" but should work fine for single quote.

I have implemented the solution proposed by @obones in https://github.com/Piwigo/Piwigo/pull/598#issuecomment-496506502 by using `pwg_db_real_escape_string` in `admin/site_update.php` on fields `{file, name, path}`. I know it won't work for some exotic characters such as "&" but should work fine for single quote.

adam commented

2026-10-04 23:49:10 +02:00

hi team,

could you please reconsider supporting apostrophe in file/folder names? I am syncing phone directories to my DIY NAS and using piwigo to build albums on top of it. Since file names and dir names on phones can be arbitrary, this restriction becomes problematic.

I understand this project is on a volunteer basis, however, i still urge to support them. Let me know if i can help in any way - what resources should i read to do dev and test?

@plegall

hi team, could you please reconsider supporting apostrophe in file/folder names? I am syncing phone directories to my DIY NAS and using piwigo to build albums on top of it. Since file names and dir names on phones can be arbitrary, this restriction becomes problematic. I understand this project is on a volunteer basis, however, i still urge to support them. Let me know if i can help in any way - what resources should i read to do dev and test? @plegall

adam referenced this issue

2026-10-05 00:01:33 +02:00

SQL Injection 'may' be possible through filenames #504

Sign in to join this conversation.

master

issue-2560-people

translation

16.x

feat/embedding-based-contextual-tagging

issue-2576-search-include-ai-in-search-results

feat/search-ocr-ai

issue-2391-update-menu-design

15.x

detect-container

issue-2386-update-filters-users-activity

issue-2362-add-filters-options-in-admin

issue-2367-imagemagick7

issue-2225-quicksearch-help

14.x

issue-2164-BatchManagerUnitMode-Redesign

13.x

12.x

issue-1657-SVG_Support

issue-1703-historySearchMethod

11.x

2.10

2.9

2.8

2.7

2.5

2.6

2.4

2.3

2.2

2.1

2.0

1.7

1.3

1.6

1.5

1.4

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Piwigo#250