The problem is valid for all legal characters not belonging to the ASCII character set, except spaces.
I can't see any reason why this is the case as long as the file name is valid. Obvious exceptions are the Directory Separators / and \, and the single quote.
This rule results in files getting "funny" names, making them hard to find by searching. The problem should be corrected. Replace the current filename checking code with code that checks for validity. The file system reports errors.

same problem with umlauts in the name of the file/folder ,
on first look it still alphanumeric but not work...

What is valid on some systems may not be on others (interoperability)

See
http://en.wikipedia.org/wiki/Filename

If a filename is legal for the file system, Joomla should also accept it.

There is also the issue that what is a valid character for a filename may
not be a valid character in a url
eg www.example.com/images/£$£%£$%^£$%.jpg

And if we allow characters that only work on one filesystem then if the
user moves the site to a new host with a different filesystem then their
site is broken

On 17 April 2015 at 09:26, ingeva notifications@github.com wrote:

If a filename is legal for the file system, Joomla should also accept it.

—
Reply to this email directly or view it on GitHub
#6775 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

well, I not sure, but maybe at least we need to allow delete these file/folders, if file_exists, or?

I use Linux, but sometimes I get files from Windows users, who use a limited character set, but that's usually not a big problem. Mac OS, being a *nix fork should be no problem. Most serious webhosts are Linux based and should be OK. Joomla should check if the filename is valid on the system it's running on. Minor differences between system should not be Joomla's concern. We must allow development to happen. No changes ever = standstill.

Minor differences between system should not be Joomla's concern
It is if we say we support hosting on Windows and *nix

On 17 April 2015 at 10:29, ingeva notifications@github.com wrote:

I use Linux, but sometimes I get files from Windows users, who use a
limited character set, but that's usually not a big problem. Mac OS, being
a *nix fork should be no problem. Most serious webhosts are Linux based and
should be OK. Joomla should check if the filename is valid on the system
it's running on. Minor differences between system should not be Joomla's
concern. We must allow development to happen. No changes ever = standstill.

—
Reply to this email directly or view it on GitHub
#6775 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I've made a temporary fix which seems to work, but the consequences have not been fully investigated. I leave that to the development team.
The fix is in the file "administrator/components/com_media/controllers/file.php", around line 240 (Joomla 3.4.1):
Comment out this part:

if ($path !== JFile::makeSafe($path))
        {
            // Filename is not safe
            $filename = htmlspecialchars($path, ENT_COMPAT, 'UTF-8');
            JError::raiseWarning(100, JText::sprintf('COM_MEDIA_ERROR_UNABLE_TO_DELETE_FILE_WARNFILENAME', substr($filename, strlen(COM_MEDIA_BASE))));
            continue;
        }

It seems to work, but no guarantee for unwanted results.

Removing that check is not a good idea.

I warned about unwanted results but I haven't found any so far. So tell us why, or it sounds more like an unfounded allegation. It won't affect me because I only use ftp and never the clumsy Media Manager, but other people use MM, and I think it would be more risky to allow them to use ftp.

The thing is that you can't create that folder/file in the Media Manager, the Media Manager takes care that the filename is safe to use in an URL. So it obviously got there using FTP.
Now the question is if we should allow deleting files/folder that were created using FTP. Personally I wouldn't allow it. If you were able to put it there using FTP, you can also remove it using FTP.

@Bakual

If you were able to put it there using FTP, you can also remove it using FTP.

It is true when the site have only one admin, or all admins use FTP,
but can be case when there a couple, and not all have access to FTP, so when one who have access make upload (with not allowed name, from Joomla point of view) then another cannot delete

And if someone able to upload the file via FTP then filename is valid, I think

@Bakual: FTP and Media Manager are not the only possibilities to upload files. The file containing parentheses was uploaded by the joomla editor plugin JCK (and not via FTP). It was uploaded by a normal user using the front-end. Now, it should be possible at the back-end to delete such a file (without having FTP access).

in case with additional extensions like JCK, they should allow to delete

@Fedik: I see the Media Manager (MM) as the central file manager for uploaded files not matter which tool was used to upload the files (otherwise it would be useless in my opinion). So MM for (a given path of) Joomla is like Windows Explorer for MS Windows. It should be possible for MM to delete any uploaded file, just like it is possible in Windows Explorer to delete a .odt file generated by Libreoffice as well as a .mp3 file generated by Audacity. It would be a funny thing, if Windows Explorer would refuse to delete a mp3-file for it was not created with Microsoft tools.

It is not designed as a file manager

On 23 April 2015 at 10:24, seth notifications@github.com wrote:

@Fedik https://github.com/Fedik: I see the Media Manager (MM) as the
central file manager for uploaded files not matter which tool was used to
upload the files (otherwise it would be useless in my opinion). So MM for
(a given path of) Joomla is like Windows Explorer for MS Windows. It should
be possible for MM to delete any uploaded file, just like it is
possible in Windows Explorer to delete a .odt file generated by Libreoffice
as well as a .mp3 file generated by Audacity. It would be a funny thing, if
Windows Explorer would refuse to delete a mp3-file for it was not created
with Microsoft tools.

—
Reply to this email directly or view it on GitHub
#6775 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

"The Media Manager is a tool for uploading or deleting files in the /images/ directory on a web server. Tools included are: uploading new file(s), deleting existing file(s), and creating sub-directories." (https://docs.joomla.org/Help34:Content_Media_Manager)

Sounds for me pretty much as a file manager (for a specific path).

If we allow to delete other files, you would have to make sure you can't delete for example files outside the media manager folder. Like by passing a filename starting with ../. I'm sure there are other possible hacks like that.
The current approach is very safe in what it allows to delete. So it surely isn't just a matter of removing that single check.

As far as I know, you can't navigate outside the media folder. In any case I think this check ONLY checks the filename. If you can navigate to other folders, it still just checks the filename. If a file exists in the MM folder, you should be allowed to manipulate it. If you can save a file using a certain name in the MM folder (even if it's uploaded by ftp), you should be allowed to manipulate it by using MM.
I have yet to see a valid argument for not doing this.

Executing the command is done via a HTTP request using query variables. All input data must be fully filtered and validated to protect the system. Removing any filtering or validation checks is not a viable option.

administrator/index.php?option=com_media&task=file.delete&tmpl=index&folder=&rm[]=index.html

The only thing stopping that URL from removing your images folder's index.html file (or whatever folder you have configured in your media manager) is the missing form token. Since the filename (and folder path) can be specified in the request, the data MUST be assumed to be untrusted and all proper security measures (input filtering, filename checks, etc.) must be executed.

I understand, but the filename check must be changed so that legal filenames are accepted. We can't accept having to destroy our filenames because of such checks. There are evidently other and better ways to check than what this routine does. I had to change the names of ALL the files in one folder because they were not accepted by MM, although there was nothing wrong with them. The person who uploaded the files had the **** of a struggle and unfortunately didn't report it to me, and when I discovered the errors I thought he had fallen back to ancient times where only American (ASCII) characters were accepted. He then told me that MM had made a lot of complaints about illegal filenames when they in fact were quite OK.
Example: "Ågerkarlens øl på løkken.pdf" is a fully legal filename but far from what MM would accept. (Except maybe for windows systems, but who uses that? :) )
However, "It's not legal.txt" is not, because of the single quote.

Errors must be fixed where the error exists. If the filename checking is wrong, it must be corrected. I don't have enough knowledge to do it in this case, because although I have good knowledge of php, I don't know the inner workings of Joomla!. All I have done is suggest a way to overcome the error, but I warned from the beginning about possible side effects, so this must be used with caution. It is not perfect, but when Joomla!'s error check works correctly, we will use it again.

Personally I have removed this test in only one of my Joomla! systems, because only one user uses the MM, and I'm the only other user. I use ftp which is much more convenient.

"Ågerkarlens øl på løkken.pdf"

It's a valid filename, but to my knowledge not an URL safe one. That's why MM refuses it.

It works perfectly in a URL, so how is it not URL safe?
Just so you can try it:
http://egni.no/Ågerkarlens øl på løkken.pdf
(Make sure you copy/paste it all, or you must write it like this:
http://egni.no/%C3%85gerkarlens%20%C3%B8l%20p%C3%A5%20l%C3%B8kken.pdf )

It may not work in an ancient Windows browser, but who cares? :devil:

Make sure you copy/paste it all, or you must write it like this:
http://egni.no/%C3%85gerkarlens%20%C3%B8l%20p%C3%A5%20l%C3%B8kken.pdf

Exactly. Not URL safe and needs to be encoded for it to work.

On Github you need to encode it because the spaces makes the script unable to complete the URL. That's why you need to copy/paste the complete URL yourself. Inside a Joomla message however, there's no need to encode. I always write my messages in html to avoid having inline styles etc. from the editor in the message because they tend to mess things up. So I write the URLs directly, without encoding. Works like a charm. Look at this URL: http://veteranvogn.no/arrangementer
and check out the html contents. It contains several links without encoding. Look especially with those starting with "a href="/KLUBBENS/PDF/2015" ("KLUBBENS" is the MM directory).
NO encoding - but every one of them works just fine.
I agree about making security checks. Disallowing fully legal filenames must not be the result of such checking. A filename is OK if the file exists or can be created. Any necessary encoding is taken care of by any modern browsers. I don't think there are many users left using MS browsers from the previous millennium, and if there were, I wouldn't hesitate to ignore them.

Like by passing a filename starting with ../. I'm sure there are other possible hacks like that.

It just a technical thing.
Since Media manager have options file_path and image_path we do not required check whether file name is valid. Enough check whether the requested file exist and belong to Media folder.

• Get requested file
• Get real path for this file realpath()
• Check whether it belong to file_path from configuration
• Remove

There just question who will do it

Sorry about late answer. There are other tasks at hand. :)
There have been many good arguments here, but there are several reasons why the current methods don't work very well:
The Media Manager can be used for a limited number of task. The security is taken care of on many levels. However, changing a filename like it's done in the JFile::makeSafe function(s), is not a sensible thing to do. If the file exits, and you change the filename before you try to delete it, how can it be removed?
A filename does not need to be URL safe. The only requirement is that the filename is legal in the file system, and if the file exists or can be stored properly, it is. For http requests it's another matter. PHP has standard conversion functions for that.
The makeSafe function is basically wrong. Neither the delete nor the upload functions should check for legal filename in ANY OTHER WAY than to check whether the file exists (so it can be deleted), or that it can be stored (for upload). Unfortunately, no path is given with the filename (the function's parameter), so the file can't always be found!
Security must be handled on a different level. For instance, when fetching GET or POST parameters, check that the form statement's referrer is in the same domain. There are many other ways. Users who aren't 110% computer oriented should NOT have access to ftp, where the risk of doing something wrong is far greater.

The same problem applies to uploading files. If a filename is legal both on the client and the server, it IS LEGAL, whether the filename itselt is URL safe or not. That's a different problem. We are talking about the computer's file system here, which couldn't care less about the WEB or HTML.
Not allowing filenames to contain fully legal characters or spaces is a severe limitation. After all, we are not in the 1980's any more!

My ONLY reason, to use Joomla! is to open for less computer oriented people to maintain the system; primarily the articles and media files. For my own websites I use my own framework, which admittedly is not so easy to maintain for "the man in the street", but there lies additional security in itself. Also the ability to store files outside of the web accessible area, is an obvious advantage when security is an issue. Something to consider for the Joomla! team?

This is a serious design flaw, and something has to be done with it. At least 90% of our filenames are "illegal" for Joomla!, although they are completely legal in the file system and represent no problem on the WEB, where names are automatically encoded and decoded. We use names like "Føttene ligger og soler seg i påsken.pdf" "all the time". No problem at all. Yes, they are encoded with "percent+HEX" for the WEB, but in the file system the names are not affected at all.

Some redesign may be necessary to remove this error. I just found that even navigation to folders with space in their name, can't be followed. What a DISASTER! Countless references are being made to files and folders with names like this, and Media Manager is completely useless. Changing all file and folder names is not an option. However, changing to a CMS with more sensible file handling might be.

On 10/23/2015 04:36 AM, msm93 wrote:

i suggest that you use "Long Path Tool" its an amazing tool google
it AND will solve your problem

Thanks, but no, it doesn't work on Linux, and it doesn't
solve Joomla's problem.

inge

For your future: http://treinvest.no
Personal pages: http://inge.vabekk.no
Mobile: +47 9050 5331
21 reasons to drink Tahitian Noni Juice:
https://youtu.be/8QCkdjcTh7g

"This is a serious design flaw"
I partly agree with this - it's certainly a design flaw. I expect there's sn extension that will get around this (Joomla Xplorer?) My power users can upload files - but can't delete funny named ones (perfectly sensible in Windows land) and they want to know why.
I am loathe to give them FTP access, with MM the damage is limited to their 'userfiles' section.
Really time to stop squirming and start addressing the problem.
Thanks for championing this issue, Ingeva.

I am closing this at this time. Media manager in its current form is not a file manager. It is designed to manage media that have been uploaded with it. If media is uploaded in other ways then it cannot be responsible for managing it.

A new media manager is being developed that will perhaps address this in the future

Well, if this ticket is closed, the only solution I see is to make use of @ingeva's idea, i.e., commenting out the condition
if ($path !== JFile::makeSafe($path)){...}