Thomas Coenen

Yep. `move_dir` deletes the folder. ```python from fs import open_fs with open_fs("mem://") as mem: folder = mem.makedir("folder") folder.writetext("file1.txt", "Hello1") sub = folder.makedir("sub") sub.writetext("file2.txt", "Hello2") mem.movedir("folder", "folder") mem.tree() assert mem.readtext("folder/file1.txt") ==...

Moving a folder into a subfolder of itself is also not a good idea at the moment. This should raise an exception.

Seems like this `mem.copydir("folder", "folder")` is accidentally already repaired in my PR #547

> Testing the equality of an FS is not something that makes sense across all filesystems. Your default implementation won't work for the more virtual filesystems. That's true. I see...

I see, but that's what the `expand_vars` option is for, isn't it? Wouldn't it be nicer if `OSFS("$HOME")` and `open_fs("osfs://$HOME")` had the same result?

Yes I wondered about that, too. Maybe `expand_vars` could be a parameter of `fs.open_fs`? That way one could pass an FTP password via an env variable.

Sorry I'm on vacation and cannot get to this until next month

I submitted a PR for this issue. I think having an `overwrite` argument in `move_file` would be nice. The only thing I don't like is that in `FS.move(...)` `overwrite` defaults...

Is v3 already planned or in development somewhere?

I found another case where the optimized and the regular code path behave differently: ```python with open_fs(fs_url) as tmp: tmp.writetext("file.txt", "content") fs.move.move_file(tmp, "file.txt", tmp, "file.txt") ``` If you move a...