Jump to content


Photo

Change Monitor in Transfer Queue


This topic has been archived. This means that you cannot reply to this topic.
6 replies to this topic

#1 uniekje

uniekje
  • Members
  • 5 posts

Posted 13 March 2008 - 04:12 PM

Whenever I user the "Edit with" option in the Context menu it downloads the file and opens it in my editor of choice. So far no problem. However as soon as the editor opens the file, the entry disappears from the Transfer Queue. When I perform the same action (Edit with) again, the file stays monitored.

Great job on the multiple file monitoring b.t.w.! It's really useful.

#2 mb

mb

    Developer

  • Administrators
  • 11526 posts

Posted 13 March 2008 - 06:14 PM

Hello ..

SmartFTP "monitors" the process (editor) that it opens. If the process dies after the first 3 seconds, SmartFTP assumes that the process created is just a "loader" for the real editor. For example if there is already an instance of the editor open the file will sometimes be loaded in the existing instance of the editor and the loader dies quickly after.
Now if the loader process takes longer than 3 seconds SmartFTP assumes that the user closed the editor and the monitor item is removed from the Transfer Queue. As you can see the current detection is not very reliable. However any other FTP client I tested using this technique suffers from similar problems. Items are either not removed after the editor is closed or the items are removed too early.
Regards,
Mat

#3 uniekje

uniekje
  • Members
  • 5 posts

Posted 14 March 2008 - 08:44 AM

Thanks for clearing that up... the editor I use does indeed use one instance which stays open. SmartFTP would (correctly) assume the process is just a loader. I guess there's no way SmartFTP could know the other instance took over. Might it be possible to disable this functionality (detecting wether or not the process dies) through a setting someday? In essence, it would 'break' the logical process but for my environment it would be a good solution.

Considering the cause of the problem, this is not a bug anymore. It's merely a request.

Edited by uniekje, 14 March 2008 - 08:58 AM.


#4 mb

mb

    Developer

  • Administrators
  • 11526 posts

Posted 16 March 2008 - 07:39 AM

If we remove the loader detection the monitor items will stay in the Transfer Queue until you close the application. This will be the plan if the loader detection turns out to be unreliable.
I have increased the time SmartFTP waits for a possible loader process to terminate.
Do you still have problems that monitor items are removed when the editor is started?

Mat

#5 uniekje

uniekje
  • Members
  • 5 posts

Posted 17 March 2008 - 09:14 AM

I've tested it and in some instances the 'problem' does not occur anymore. This struck me as weird, so I decided to investigate it further. Apparently the filesize being edited is the main factor, at least with the editor I'm using (PHP Designer). Apparently the loader process in this editor slows down considerably when the filesize increases. Maybe it's wise (then again maybe not) to determine the waiting period according to the size of the file being edited?

#6 mb

mb

    Developer

  • Administrators
  • 11526 posts

Posted 19 March 2008 - 01:20 AM

Hello ..

We have disabled the process monitor in the latest version. It means you have to manually remove the items from the Transfer Queue if you don't want to monitor the file anymore. However if you don't do it they will automatically be removed after SmartFTP is restarted.

Regards,
Mat

#7 uniekje

uniekje
  • Members
  • 5 posts

Posted 20 March 2008 - 10:37 AM

Cool... it works great for my situation. I don't mind deleting the monitors by hand.
Btw, you're right, other tools allowing remote editing have the same problem, plus they don't work as great as SmartFTP ;) .