File paths should not be urlencoded in the file_managed table (breaks FileField Sources when filenames have spaces)

The file path shouldn't be URL encoded in the database. My guess here is that we're not properly urldecoding something on the way in. Which source are you experiencing this problem with? We should call urldecode() *before* the call to filefield_sources_save_file().

(This may have already been fixed as part of #967992: remote.inc: Get filename from Content-Type or Content-Disposition, but is not yet in an official release.)

I couldn't confirm this problem with normal file uploads, referencing existing files via autocomplete, nor through the file attach approach. I need more information on how to reproduce the problem.

In the database, files are stored unencoded:

public://newfiles/My file with spaces.png

This may have been fixed already as part of #967992: remote.inc: Get filename from Content-Type or Content-Disposition, which increased our file name robustness for the remote URL source.

I get this error when selecting an existing file through elFinder 0.7 if the file has spaces or contains non ASCII characters. I'm using FileField Sources 1.6. Spaces in directories works fine. The quickest fix I found was to url decode the file path in the filefield_sources_save_file function. But I dont know if this is the best way?

$filepath = urldecode($filepath);

// Begin building file object.
$file = new stdClass();

I get this error when trying to upload a file with spaces:

Warning: filesize(): stat failed for [path/to/file] in filefield_sources_save_file() (line 423 of /[path/to/webroot]/sites/all/modules/filefield_sources/filefield_sources.module).
The specified file [path/to/file] could not be copied, because no file by that name exists. Please check that you supplied the correct filename.
File upload error. Could not move uploaded file.
The selected file could not be used because the file does not exist in the database.

(using FileField Sources 1.8 with elFinder 0.8)

I get this error as well, when using the elfinder File browser option, added by the elFinder File Field Source module added to it. Any progress on this?

Switched to major as this is a pretty big piece of functionality that is being broken.

This problem is occurring for me as well. Below is a patch applicable to the 7.x-1.9 release.

Isnt this something that would be solved in combination with https://www.drupal.org/project/transliteration ?

Same problem here, with special chars like french accents (é, è etc...).
Patch provided in #7 by captainpants seems to do the trick, thanks !

Leeteq
Isnt this something that would be solved in combination with https://www.drupal.org/project/transliteration ?

Transliteration seems to be used in filefield_sources module, for file names but not for path ?

function filefield_sources_clean_filename($filepath, $extensions) {
  global $user;

  $filename = basename($filepath);

 <strong> if (module_exists('transliteration')) {
    module_load_include('inc', 'transliteration');
</strong>
    $langcode = NULL;
    if (!empty($_POST['language'])) {
      $languages = language_list();
      $langcode = isset($languages[$_POST['language']]) ? $_POST['language'] : NULL;
    }
    $filename = transliteration_clean_filename($filename, $langcode);
  }

Moving this to elFinder. Because Drupal core does not urlencode() paths when saving files, neither should elFinder. It seems as though when it's uploading files it may be encoding the names first, which it should not be doing.

Moved #34