Renaming a folder over existing other folder is broken

[Tronic]

Given folder A and B, if the user renames A to B, afterwards Droppy only displays folder B with the prior content of A. However, on the filesystem nothing happens, A and B still contain their original files. Trying to access the files via Droppy gives 404 errors.

Renaming should check for success of the actual disk operation (that the name didn't exist), and only update Droppy's internal database if so.

[vahtos]

Note that naming conflicts for files are prevented in the UI. Ideally, in both cases Droppy would provide a prompt to change the name (similar to how many desktop file explorer apps work). A simpler fix would be to implement the same behavior for folders that is used for files currently.

[vahtos]

Renaming a file to the name of a folder is permitted in the client, but causes an error on the server: [ERROR] EISDIR: illegal operation on a directory, rename '/home/vahtos/.droppy/files/whereami' -> '/home/vahtos/.droppy/files/New folder'

Couple of notes about this:

• This makes the cache get out of sync with the actual directory structure on the server: the file is not renamed, but disappears in the client, when the folder is deleted, the phantom file shows in the client with the name of the deleted folder.
• This brings up the issue that there is not currently any validation of changes made on disk(?) If an operation fails for any reason, it will cause other unexpected states.
• You cannot do this illegal operation in the opposite direction. You cannot name a folder to the name of a file. That indicates (not confirmed yet) that the root issue here is that renames are only checked against file names -- they should be checked against the type of the object being renamed (folder or file)

[vahtos]

I am at a loss here. In the middle of debugging this, I can no longer reproduce any of it. I've made no changes, I restarted droppy, I tried reverting to previous commits (before v1.0.1), I deleted the cache, I tried a different browser. I even tried an entirely different instance of droppy, running (v1.0.1) on a different machine.

@markhughes can you reproduce this?