Project

General

Profile

Actions

Bug #93972

open

Files with "+" in filename can't be replaced

Added by Christian Toffolo about 3 years ago. Updated 9 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2021-04-22
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
7.4
Tags:
Complexity:
Is Regression:
Sprint Focus:
On Location Sprint

Description

In TYPO3 10 LTS, files with "+" in filename can't be replaced using the replace tool in Filelist module.
Instead, the new file is uploaded but it doesn't replace the old one.


Files

sky two.jpeg (3.78 KB) sky two.jpeg Riccardo De Contardi, 2022-08-14 14:07
sky+one.jpg (89.5 KB) sky+one.jpg Riccardo De Contardi, 2022-08-14 14:07
(2)sky+one.jpg (37.8 KB) (2)sky+one.jpg Riccardo De Contardi, 2022-08-14 14:10
(2)sky two.jpeg (19.9 KB) (2)sky two.jpeg Riccardo De Contardi, 2022-08-14 14:10

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #99893: + in directory name is crashing the File > List moduleClosed2023-02-09

Actions
Actions #1

Updated by Martin Kutschker about 3 years ago

Troubles with URL encoding? A plain + in a URL means space, just like %20.

Updated by Riccardo De Contardi over 1 year ago

Is this issue still present?

I tried with the files attached on TYPO3 12.0.0-dev (latest main) - just rename them so their name is identical - and I had no trouble AFAICS

- every time the file has been automatically renamed with the underscore "_" instead of "+" or the space
- the file has been replaced (with the usual modal dialog)

Is a different test necessary?

Actions #3

Updated by Christian Toffolo over 1 year ago

Hi Riccardo,
maybe you can't reproduce the bug because the files with "+" in the name are renamed replacing "+" with "_" if uploaded via TYPO3.

Instead the problem arise when the file have "+" in the filename when already in the fileserver in case it has been uploaded externally of TYPO3 so not renamed.

Actions #4

Updated by Riccardo De Contardi over 1 year ago

  • Status changed from Needs Feedback to New

I guess that this behavior is expected... As you say, TYPO3 renames the files on upload by itself; if the file with a "weird" name is already present on disk it is not replaced;

The steps to reproduce the problem on TYPO3 11.5.x are the following

1) fresh TYPO3 11.5.x installation
2) Download the files (2)sky+one.jpg and (2)sky+one.jpg attached here inside fileadmin/Images (or another TYPO3 asset folder you like)
3) rename them

sky two.jpeg
sky+one.jpg

4) download the files sky+one.jpg and sky+one.jpg attached here somewhere else
5) TYPO3 > Filelist module > folder: "Images" > upload files > choose to upload the new files
sky two.jpeg
sky+one.jpg

Result:

- the "old" files are kept
- the "new" files are renamed accordingly the TYPO3 rename rules ("_" instead of "+" and " " (space))

As I said, I think that this behavior is what I expect to happen; Maybe the correct approach here would be to create a scheduler task "sanitize filenames" that should scan the file repositories and correct the wrong filenames... what do you think?

Actions #5

Updated by Christian Toffolo over 1 year ago

Use case: an editor has a "sky+one.jpg" file and wants to replace it. The editor uploads a new file to replace it and TYPO3 informs him that he replaced the file when in fact it didn't and uploaded the new file. If this file is in a long list of files, the editor probably won't even notice what happened.

Sure this is a minor bug because it affects a rare use case, but it shouldn't be treated as expected behavior IMHO.

Actions #6

Updated by Riccardo De Contardi over 1 year ago

@Christian Toffolo I am saying is that the scenario in which

1. There is already a file on filesystem named sky+one.jpg that for some reasons has not been handled by the TYPO3 filename sanification process

2. The editor uploads a file using the TYPO3 interface with the same name: sky+one.jpg .
This time the filename sanification is triggered, so the file is renamed sky_one.jpg

3. TYPO3 does not know that there's already a file named sky+one.jpg, so this is kept and a new one called sky_one.jpg is added while the old file is kept.

Seems IMHO what should happen and so I think this might be a feature and not a bug... maybe I'm wrong. I would like to know opinions on that.

Why this happens? I guess that the actual file comparison and overwrite process seems to happen after the sanification process.
as proof of this, if I try to upload ANOTHER file (still using TYPO3) still named sky+one.jpg, the "warning modal" says that there is already a file named sky_one.jpg, not sky+one.jpg!

Would it be wise to alter the order of execution of these processes? what would happen in this case

1. there is already sky+one.jpg on disk
2. editor uploads sky+one.jpg using TYPO3
3. TYPO3 compares sky+one.jpg (old) to sky+one.jpg (new) -> the filenames are identical -> asks if it should be overwritten -> if answer is YES ->
4. TYPO3 overwrites the file
?? 5. TYPO3 sanitizes the filename to sky_one.jpg
?? 6. TYPO3 deletes sky+one.jpg

right? Or do you think that in this case the sanification process should be skipped at all?

I also wonder what would happen if for some reason there are on disk files named:

sky+one.jpg
sky one.jpg

if you upload sky+one.jpg what would happen? just the first is replaced?

I suggested that the anomalous situation about the presence of files not sanitized by TYPO3 could be handled ex post using a scheduled process or something similar.

Actions #7

Updated by Christian Toffolo over 1 year ago

For the use case of this issue, the editor is not simply uploading a file using the TYPO3 interface, the editor is replacing a file using the replace tool of TYPO3.
Maybe you are missing this important difference.

Actions #8

Updated by Xavier Perseguers about 1 year ago

  • Related to Bug #99893: + in directory name is crashing the File > List module added
Actions #9

Updated by Benni Mack 9 months ago

  • Sprint Focus set to On Location Sprint
Actions

Also available in: Atom PDF