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?

[markhughes]

Sorry @vahtos I haven't had a chance to try this one out the past few months.

There are a lot of places I've resolved already where we don't do early enough checks, but I may have missed some in my sweep.

My focus has been getting the codebase into a modern more maintainable standpoint and a lot of this should get resolved while pulling it apart.

This currently doesn't do anything, and the error will just log:

https://github.com/droppyjs/droppy/blob/canary/packages/server/lib/commands/rename.js#L26

I really need need to move it to a handled promise instead (more modern maintainable changes)