The internal path was matched without the last "/" which caused
"files_trashbin" to also match when the internal path was "files".
This adds the missing slash for the comparison.
This fixes an issue when renaming files from a flat list view like
"Favorites" or "Shared with you", in which case the path needs to be
present in the response to make sure the data-path attribute is properly
set in the JS side.
To make it possible for the web UI to correctly display the tag/favorite
information after a rename, this information is now returned in the
rename response
Whenever tags are updated, they need to be updated in the file list's
file info array as well.
This commit also adds unit tests and makes sure that whichever tags are
sent back by the server after update are used when updating
attributes/fileinfo.
Make it possible to drop files below the table even if the table is
smaller than the window height.
Added a check to make sure upload is not triggered on invisible lists.
Apparently `normalizer_normalize` is not verifying itself whether the string needs to be converted or not. Or does it at least not very performantly.
This simple change leads to a 4% performance gain on the processing of normalizeUnicode. Since this method is called quite often (i.e. for every file path) this has actually a measurable impact. For examples searches are now 200ms faster on my machine. Still not perfect but way to go.
Part of https://github.com/owncloud/core/issues/13221
Isset is a native language construct and thus A LOT faster than using strlen()
On my local machine this leads to a 1s performance gain for about 1 million paths. Considering that this function will be called a lot for every file operation this makes a noticable difference.
`normalizePath` is a rather expensive operation and called multiple times for a single path for every file related operation.
In my development installation with about 9GB of data and 60k files this leads to a performance boost of 24% - in seconds that are 1.86s (!) - for simple searches. With more files the impact will be even more noticeable. Obviously this affects every operation that has in any regard something to do with using OC\Files\Filesystem.
Part of https://github.com/owncloud/core/issues/13221
We already use `.text()` here which automatically properly encodes the string. Thus the string will be double-encoded and look ugly. (i.e. when you search for ">" you will see "No results found for >")
Fixes itself.
