Bad design of FS Interface?!? (Move dir inside itself prob.)

[djorge]

I have been studying the FS interface of total commander making a useless plugin.
Basically the test plugin reads (via F5 key) one or more XML file which describes a file system and it recreates this structure in the FS panel. The user can after, copy, move, make dir, delete any item of the FS panel and later save the xml modified. The idea was to support all the FS interface.

I was implementing the FsRenMovFile function and now i am facing an unexpected
problem that i don't know how to solve.

Scenario:
My xml file has the following tree:

Dir B
|
|---FileB1.txt
|
|---FileB2.txt

The problem happens when i try to move a dir inside itself. TC always makes a call to
FsMkDir first, and i don't think this is a good idea. It is the plugin that should have
responsibility to create non-existing directories.

For instance, if i try to move "Dir B" inside "Dir B", TC will make a call to FsMkDir
to create "\Dir B\Dir B", a call to FsRenMovFile to move file FileB1.txt, FileB2.txt, a call
to FsMkDir to create "\Dir B\Dir B\Dir B", move files, "\Dir B\Dir B\Dir B\Dir B",
,move files, Create Dirs,........................... CRASH

The FsMkDir is called repeatability until the the MAX_PATH for a path has been reached, and crash....

In my opinion, TC should not call FsMkDir, and it should be the plugin to create the
missing directories. With that design there is no way to know wether one is moving
a directory to itself. This is only possible to know in FsRenMovFile where the plugin
receives the source path and destination path.

It seems that i have only two options:
1- Comment FsMkDir disabling the user to create a directory, and create the
missing directories in FsRenMovFile.
2- Disabling FsRenMovFile option.

I don't know if i am forgetting something or is this a bad design of TC FS interface?