Multiple edit feature doesn't seem to work correctly with MDI editors.

I have tried the multiple file edit feature with two different editors. Editing one file at a time works fine, but when I edit multiple files, it seems to only properly save the first file. The other files are trying to save to the wrong file path. Does this feature not work with MDI editors?

I admit that there may be problems with such editors. But not problem that you describe. Can you provide me step-by-step description of what you are doing, so I can try to reproduce the problem myself?

I have tried two different MDI editors and get the same result. These freeware editors are Crimson Editor and PSPad. Here are the steps I do to create the problem:

- Right click on file1.cpp and select Edit. Editor starts up and loads file1.cpp just fine. I can make changes to this file and save without any problems.

- Right click on file2.cpp and select Edit. Editor that is already open and used for editing file1.cpp seems to correctly load file2.cpp for editing. But after making changes to file2.cpp and trying to save, I receive an error indicating the save failed.

Here is my take on the problem. When editing first file, it is loaded into a temporary directory scp55906. When editing second file, it is loaded into temporary directory scp57781. When trying to save second file, it tries to save into temporary directory scp55906 and not scp57781.

From you post I've understood that it's WinSCP who displays the error. I have tried PSPad and I have realized that is the editor's error.

This is "expected" behaviour. Let me explain how MDI editors work and why WinSCP does not work with them:

WinSCP needs to know when the edited file is closed:
1) So it can remove the temporary directory where it is stored.
2) Due to Windows limitation it can watch for modification of up to 64 files. If it would not detect that the files is closed, you'll soon reach the limit.

The only working way, I know about, how to detect that the file is closed, is to watch for termination of the application that was launched to edit the file.

Here comes the problem with editors that can open more files in one process. If the editor is already running and the WinSCP run second instance to open new file, the second instance just notifies the first to open the new file and exits immediately. Hence WinSCP expects that the file was closed as well and tries to delete the temporary file.

As PSPad does not lock the opened file, WinSCP succeeds deleting the directory. But then, when you save the file in PSPad it realises that the directory, where the file was opened from, no longer exists. And displays the error.

So far I see no solution for the problem. Except that you configure the editor to use one process for every file. Some MDI editors have such option.

Any idea is welcome.

Thanks for the information. Could you just monitor the modification date of the temporary files and delete the temporary files when WinSCP is closed?

Thanks for the information. Could you just monitor the modification date of the temporary files and delete the temporary files when WinSCP is closed?

See above.
You would soon reach the 64-files limit. It will happen the sooner the more often you close the file in editor and reopen it again from WinSCP.

martin wrote:

Thanks for the information. Could you just monitor the modification date of the temporary files and delete the temporary files when WinSCP is closed?

See above.
You would soon reach the 64-files limit. It will happen the sooner the more often you close the file in editor and reopen it again from WinSCP.

Instead of using windows functionality to monitor file modification, couldn't you just keep track of the temporary files yourself and check the modification dates on your own?

Instead of using windows functionality to monitor file modification, couldn't you just keep track of the temporary files yourself and check the modification dates on your own?

I do not like the approach. I may end up monitoring several tens to hundreds of files. If I do it continuously, it would have impact on machine performance. If I do it in intervals, there would be several seconds delay beteween file being modified and uploaded.

martin wrote:

Instead of using windows functionality to monitor file modification, couldn't you just keep track of the temporary files yourself and check the modification dates on your own?

I do not like the approach. I may end up monitoring several tens to hundreds of files. If I do it continuously, it would have impact on machine performance. If I do it in intervals, there would be several seconds delay beteween file being modified and uploaded.

Fair enough. I just think think not being able to use one MDI editor to edit all the files reduces the benefits of the multi-edit feature. Maybe you could have a special option for this. Thanks for your replies.

Fair enough. I just think think not being able to use one MDI editor to edit all the files reduces the benefits of the multi-edit feature. Maybe you could have a special option for this. Thanks for your replies.

I'm aware of that.
I was also considering the option already. However I think that it is too "technical" decision for regular user. I'll think of something else.