Project

General

Profile

Actions

Bug #63603

closed

Unexpected behaviour with file upload

Added by Raphael Zschorsch over 9 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Must have
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2014-12-05
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
5.5
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

When will this be changed in file typo3/sysext/core/Classes/Utility/File/ExtendedFileUtility.php?

                // @todo can be improved towards conflict mode naming
                if ($this->dontCheckForUnique) {
                    $conflictMode = 'replace';
                } else {
                    $conflictMode = 'cancel';
                }

Currently it is not possible to not overwrite an image and to have expected behavious as before that a number (01, 02, etc.) is appended to the file. Instead an error is thrown that no unique filename exists, because there is only 2 options possible: replace or cancel, but the already implemented feature for changeName is never being called, because of the JavaScript confirm, giving back true or false.


Files

2015-01-02-fal-upload-override-001.png (49.6 KB) 2015-01-02-fal-upload-override-001.png Upload after adding the same files again Philipp Gampe, 2015-01-02 19:36

Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Task #67466: Filelist file upload "overwrite" messageClosedAlina Fleser2015-06-15

Actions
Related to TYPO3 Core - Task #55419: Use enumeration for handling conflict in file namesClosedDaniel Goerz2014-01-29

Actions
Actions #1

Updated by Mathias Schreiber about 9 years ago

  • Status changed from New to On Hold
  • Assignee set to Mathias Schreiber

Hi Raphael,

I don't get your intention, maybe you can try to rephrase.

You want to have "file.jpg" and on upload "file_01.jpg"?

In your case:
Do the files contain the same content?

Actions #2

Updated by Raphael Zschorsch about 9 years ago

Hi Mathias,

Thanks for replying. To answer your question: Yes, file and filename are identical. Currently, what happens on uploading the file, is a JavaScript confirm to overwrite the existing file or not. I'm currently not able to access an installation as I'm on the road but I'll try to give more details, if needed, when I'm back (latest on Monday).

Actions #3

Updated by Mathias Schreiber about 9 years ago

Ok, thanks for the feedback.
I am a bit puzzled to be honest, because the entire idea of FAL is to NOT have the file_01.jpg?

I think I am missing something here :)

Actions #4

Updated by Philipp Gampe about 9 years ago

@Matthias: This is not about the internal renaming for each Content Record (like in previous TYPO3 versions), but about the file upload dialog.

The JS for this dialog needs to be tuned to allow more choices and better error handling.

Actions #5

Updated by Philipp Gampe about 9 years ago

Especially for drag&drop uploading, errors need to be handled via client side, inside the JS, because the page will not reload.

Actions #6

Updated by Philipp Gampe about 9 years ago

The problem is, that you can only one dialog for all uploaded files to either override the files or leave them alone.

Please take a look at Upload after adding the same files again

I hit cancel on the dialog and all files are not uploaded. I could have easily overridden all files that way without further notice.

Actions #7

Updated by Raphael Zschorsch about 9 years ago

When I upload a file and then try to upload that file again, I get the following question:

"Shall existing files be overwritten?"

If I click "Ok" here, which suggests the file should be actually overwritten, everything works fine as would be the logic behind FAL as you mention it.

If I click "Abort", which in context to the question, if existing files should be overwritten, should, IMO, mean "No, but upload them and append _01, _02, etc.", I get the following error message:

"No unique filename available in "/user_upload/bilder/test2/"! Upload of the file "image.jpg" failed!"

That is because the logic behind "Abort" is not how I described it, but "Abort everything" which doesn't make any sense in context to the question that is asked in the backend. Therefore, and to maintain earlier functionality, because in fact it is a user friendly way to have different versions of files for an editor, there shouldn't be a coFnfirm with true/false but three options "Yes, No, Abort". And in my first post, I can see in the core, that this functionality is actually there, but never achieved because of the yes/no confirm box.

Another solution would be to change the question in the confirm box, although it would mean decrease in user friendliness for editors. 

How do you propose to solve it, if the idea behind FAL is to not have _01, _02, etc.?

Actions #8

Updated by Frans Saris about 9 years ago

Although it seems like a easy fix I'm afraid it isn't. See the releated issue I linked.

Actions #9

Updated by Raphael Zschorsch about 9 years ago

Seems to me that this is more an endless discussion again about a trivial thing, given the date of the bug entry you linked. I don't get why, even more in this case, because it's a LTS version, clearly unfinished stuff makes it to the core of TYPO3. The way FAL was introduced is just one complete mess.

Actions #10

Updated by Mathias Schreiber about 9 years ago

While I agree that FAL has a lot of things that need to be improved, I can't tell any part within TYPO3 that you can consider "finished" :)

I think this discussion is not endless, but rather fruitful because we need more feedback on the expected behavior by you, the users.

What does not help is an attitude like "why didn't you see this?" because noone missed behavior on purpose.

Thus I consider it important to discuss these things until we have reached consensus about how it should behave and then implement it.

Actions #11

Updated by Raphael Zschorsch about 9 years ago

I'm sorry, if my attitude seemed inappropriate, it wasn't my intention to blame anyone, but to point out, that everything is ready for the feature (3 options) and then a confirm box is used (true/false). This is not really about missing features IMHO, but just unfinished. I'm okay with a piece of software not really being "finished", but to introduce a new feature and to remove features along the way that have been there for ages with no mention of it that it has been removed is rather difficult to understand. Of course I'll be giving more feedback along the way, because that's important as you say, but the first and most important thing, besides NEW features or how it should behave, should be reintroducing the OLD ones first.

Actions #12

Updated by Mathias Schreiber about 9 years ago

Maybe that came out too harsh from my side, my apologies.

We will try to tackle this issue during our FAL sprint in Essen/GER in Q1/2015.
Again: Thanks for clearing up the expected behavior.

Actions #13

Updated by Andrea Herzog-Kienast about 9 years ago

For me the behaviour is as expected. I have TYPO3 installations with several editor who very often upload the same files again and again. This is not very useful.

The normal way most operation systems behave is not to allow to upload a file with the same file name again. Normally you will be asked to replace this file.

But for me it should be possible to replace a file in FAL by uploading the same filename again ("Do you like to replace yes/no"). But this is a feature wish :).

Actions #14

Updated by Xavier Perseguers almost 9 years ago

While I understand and agree with the former behaviour having been "removed" and I understand the problematic of keeping multiple versions of the same file "automatically by suffixing", I have the feeling that it is not the general use case for FAL usage:

  • It most cases, the user is actually willing to update an image or a file and not get another version into the system, so current behaviour of either replacing or aborting is the one making most sense
  • It is quite easy for people to manually rename their file prior to upload if they really want multiple versions of the same file

However, I read the concern about aborting everything or nothing and, together with an enhancement with that "weird" behaviour, I would suggest something that would certainly make everyone happy:

  • DO NOT ask the question regarding overwriting or not prior to uploading, but wait until there is a case
  • This question should be asked for each and every file, not "globally" (with an option to say "do the same for other conflicts")
  • To this regards, instead of telling the user "there is already file XY, do you want to overwrite it, since the file is already (emporary) uploaded but not moved to its final place, we could do:
    • Give additional info such as date of last modification / file size of existing one vs new one
    • Give user the possibily to 1) cancel (this very specific file upload) or 2) replace existing file (current behaviour) or 3) upload anyway and auto-rename

This way we will even enhance the UX of uploading file by not asking useless question (what to do if existing when this does not make sense) and let user do exactly what he wants.

In addition, we could even think of preventing overwrite/renaming if checksum is identical since it does really not make sense to have multiple times the same file (I hardly see a good reason to do so).

Actions #15

Updated by Frans Saris almost 9 years ago

+1, sounds like a proper solution.

Actions #16

Updated by Andrea Herzog-Kienast almost 9 years ago

I wrote someting down here: https://forge.typo3.org/projects/typo3cms-core/issues?query_id=167

Most other file systems act like this.

Actions #17

Updated by Gerrit Code Review over 8 years ago

  • Status changed from On Hold to Under Review

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41338

Actions #18

Updated by Gerrit Code Review over 8 years ago

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41338

Actions #19

Updated by Gerrit Code Review over 8 years ago

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41338

Actions #20

Updated by Gerrit Code Review over 8 years ago

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41338

Actions #21

Updated by Frans Saris over 8 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #22

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF