Baffled that no-one else has raised or perhaps it's my research that's at fault. Either way.

I'm running 2.4.5 and whilst I can drag and drop in Files & Images, the actual sort order isn't saved. So the next time I visit the folder the contents has fallen back to it's previous order, presumably determined by the last modified date. I notice that the directory does pay attention to SortOrder though. I ran a bit of sql on the table which worked well and allowed me so sort the contents alphabetically.

SET @rownum=0;

UPDATE `File` t, (SELECT @rownum:=@rownum+1 rownum, file2.* FROM `File` file2 WHERE file2.ClassName = 'Folder' AND file2.ParentID = [PARENTFOLDERID] ORDER BY `name` ASC) r 
SET t.SortOrder = r.rownum 
WHERE (t.ID = r.ID);

It's not ideal, is there a work around? Is there even anything wrong? Thanks everyone.

I ran into the same problem. For me it's caused by DataObjectManager. I've asked it not to replace the regular Asset Manager (by setting DataObjectManager::allow_assets_override(false); in _config.php). However, DOM still adds the SortableDataObject extension to the File class, even though I asked it to not replace the manager (see dataobject_manager/code/SortableDataObject.php, line 19).

Adding SortableDataObject to File results in the built-in sort order being ignored. The built-in works through the column Sort in the DB, Uncle Cheese's code works through the added column SortOrder, which takes precedence. However, the former gets altered when you re-order the folders, the latter is used when the list is rendered. Thus, the is that you can't change the order through the interface.

The trick was to remove the SortableDataObject extension from the File class:

SortableDataObject::remove_sortable_class('File');

So, in conclusion: DOM adds and uses a new sorting column that overrides the built-in. Changing the sort order in the interface doesn't change the new sort order column, so nothing changes. Remove the SortableDataObject extension from File, and your problem will be solved.