Automatic upload of changed file - if application was runnin

Please, if you could make this little requirement.

Problem:
As I see, the WinSCP can upload only files opened from WinSCP by application that wasn't running before. But there is problem, if the application was running before opening the file.

Solution:
The easy way is to show the modal dialog that tells, that WinSCP can not recognize when the file is changed ... and click Upload after you end the manipulation with the file. This dialog will have Upload button, after you click it, the temporary file will be uploaded and dilog will close.
It is same as running applications from packed file in Total Commander by choosing "Unpack all and execute".

You can also show non-modal dialog for all opened files.

I'll maybe go this way.

Just for clarification: there is no problem detecting that file was changed, there is prbolem detecting that the file was closed. So WinSCP can still automatically upload the changes when the file is saved. User just have to let WinSCP know once it closes the file.

Another issue is detection that the above should be actually done. I do not know how to detect that the process started actually passed the file to other process. There can be heurictic methods deciding that this happen by unusually short time the process has runned (below 1 second???). But this will not be reliable :-(

I use Crimson Editor primarily, and though it supports multiple files being opend at the same time, I have similar problems when editing multiple files from WinSCP. You mentioned that WinSCP can upload the changes just fine, it just can't tell when the file was closed, but it seems to me that WinSCP thinks the file was closed before I can even start editing. Here's what happens for me:

Locate a file in WinSCP
Double-click it to edit in Crimson Editor
(changes made to this first file are uploaded properly, no matter what happens below)
Locate another file in WinSCP and double-click it to edit in Crimson Editor
The file loads properly in Crimson Editor, and seems at first to be fine
When I make changes and try to save the file, Crimson tells me the file does not exist, and indeed it doesn't

It seems that WinSCP is creating the temporary file, Crimson opens it, then WinSCP deletes the file immediately, as if the file was closed (or so it seems to me). Maybe this is something strange that Crimson is doing to cause WinSCP to think the file was closed, but I can't imagine what's going on. Perhaps this should go in the support forum if this behavior is due to some problem in WinSCP, but to me it seems related to this original request.

Any information on getting this to work would be greatly appreciated. Thank you.

-Gul

Gulopine wrote:

... but it seems to me that WinSCP thinks the file was closed before I can even start editing.

Yes, that's it.

I have just collected some info from several past posts a put the to new article

this isn't very related to this thread, but partially. my problem is that i'm frequently connected to a sluggish ssh server and hence my file changes take some time (y'know a full second or two) to upload after i've saved them. i'm typically using a notepad-like text editor (scite, btw, & comes highly recommended), saving and then winscp (having opened the file for me) happily uploads my changes, this works very well and for the most part i'm pleased with the feature.

HOWEVER, as the indecisive and buggy coder that i am, i'll frequently save, then quickly add a semicolon or conduct some other minor change and save again, in quick succession. this causes WinSCP to NOT upload the second save (or any subsequent saves) until i hit "ok" on the dialog box informing me that an upload was already underway and it cannot upload the same file yet. Besides violating my god given rights to DWIM (do what i mean) this also causes me to go "grrrr" and after several such incidents in an evening i begin searching for another graphical scp client... i never find one though and then i like winscp again and can overlook this fault. today i thought i'd do something constructive with my emotion of "grr" and bring this to your attention.

on a related note, this same server will also disconnect me after a certain amount of time - i've noticed that winscp might keep up to 3 connections, and depending on which one has been neglected it will cause differing problems. For example,
- if the main "browsing the filesystem" connection hasn't been used, i'll have to reconnect winscp and re-open any documents i might have already opened from the server.
- if the "upload an editing file" connection hasn't been used, upon saving to that disconnected connection i'll get an error, then i'll copy the entire text of the file to the clipboard, re-open it from the server and paste it in, then save (grumbling all the way).
- if the "copy/duplicate/move/command" connection has been severed subsequent calls to execute any of those commands will make winscp show me an error and then i'll just have to execute the command again, i suppose this one is the least troublesome.

So - this really is a superb piece of software, i've just got a few gripes and maybe you have heard these from others. Thanks for listening.

b wrote:

HOWEVER, as the indecisive and buggy coder that i am, i'll frequently save, then quickly add a semicolon or conduct some other minor change and save again, in quick succession. this causes WinSCP to NOT upload the second save (or any subsequent saves) until i hit "ok" on the dialog box informing me that an upload was already underway and it cannot upload the same file yet. Besides violating my god given rights to DWIM (do what i mean) this also causes me to go "grrrr" and after several such incidents in an evening i begin searching for another graphical scp client... i never find one though and then i like winscp again and can overlook this fault. today i thought i'd do something constructive with my emotion of "grr" and bring this to your attention.

OK, I can make the error message suppressible. I you have had asked for this few days sooner, I could be in today's release already :-)

However be warned that overwritting the file that is being uploaded at the same time may have unpredictable results :-)

on a related note, this same server will also disconnect me after a certain amount of time - i've noticed that winscp might keep up to 3 connections, and depending on which one has been neglected it will cause differing problems.

You should setup keepalives to avoid being disconencted.

- if the "upload an editing file" connection hasn't been used, upon saving to that disconnected connection i'll get an error, then i'll copy the entire text of the file to the clipboard, re-open it from the server and paste it in, then save (grumbling all the way).

I believe that when the background transfer connection is disconnected, new one is opened. But maybe it does not work as well as I think. Can you give me more details? What is the error, etc.

- if the "copy/duplicate/move/command" connection has been severed subsequent calls to execute any of those commands will make winscp show me an error and then i'll just have to execute the command again, i suppose this one is the least troublesome.

Sorry I do not understand this one. Try again :-)

martin wrote:

- if the "upload an editing file" connection hasn't been used, upon saving to that disconnected connection i'll get an error, then i'll copy the entire text of the file to the clipboard, re-open it from the server and paste it in, then save (grumbling all the way).

I believe that when the background transfer connection is disconnected, new one is opened. But maybe it does not work as well as I think. Can you give me more details? What is the error, etc.

OK, you were right, it does not work that good :-( Pity that you have not reported this sooner.

I had to delay the release by one day for some reason, gaining time to implement some of your requests:

martin wrote:

b wrote:

HOWEVER, as the indecisive and buggy coder that i am, i'll frequently save, then quickly add a semicolon or conduct some other minor change and save again, in quick succession. this causes WinSCP to NOT upload the second save (or any subsequent saves) until i hit "ok" on the dialog box informing me that an upload was already underway and it cannot upload the same file yet. Besides violating my god given rights to DWIM (do what i mean) this also causes me to go "grrrr" and after several such incidents in an evening i begin searching for another graphical scp client... i never find one though and then i like winscp again and can overlook this fault. today i thought i'd do something constructive with my emotion of "grr" and bring this to your attention.

OK, I can make the error message suppressible. I you have had asked for this few days sooner, I could be in today's release already :-)

If you save the file while the previous change is being uploaded, re-upload is scheduled instead of showing the error message.

- if the "upload an editing file" connection hasn't been used, upon saving to that disconnected connection i'll get an error, then i'll copy the entire text of the file to the clipboard, re-open it from the server and paste it in, then save (grumbling all the way).

I believe that when the background transfer connection is disconnected, new one is opened. But maybe it does not work as well as I think. Can you give me more details? What is the error, etc.

Dropped background connection is detected immediatelly, not only after you attempt to transfer something over it. Thus when you finaly start transfer, new connection is opened.

Martin -
hot, sounds like you really solved these "properly", kudos!

Dropped background connection is detected immediatelly, not only after you attempt to transfer something over it. Thus when you finaly start transfer, new connection is opened.

If you save the file while the previous change is being uploaded, re-upload is scheduled instead of showing the error message.

then there was this one:

Quote:
- if the "copy/duplicate/move/command" connection has been severed subsequent calls to execute any of those commands will make winscp show me an error and then i'll just have to execute the command again, i suppose this one is the least troublesome.

Sorry I do not understand this one. Try again Smile

when you right-click on a file, you get a context menu that, among other things, lets you copy or duplicate a file - i use these often (incidentally, it'd be nice to have a "create empty file" command in this menu too, akin to "create directory", but the duplicate accomplishes this...) When you do one of these, first it spawns a new connection (which i question as the right thing to do, but alas) then it prompts you for the "parameter" for that command, in the case of duplicate: the destination file name, then does it, then it leaves that connection open. subsequent calls to these commands work more quickly b/c it won't connect again, though if you're too "late" it'll have been severed and calling duplicate will (and here i revise my earlier statment) cause WinSCP to report a connection error and reconnect entirely, invalidating any open buffers you may have as well as it's cached directory/filesystem tree. also, as an unexpected inconvenience, the reconnect will bring you back to the directory you had been in (thinking it's being helpful i suppose), in my case, i have symbolic links from my home directory to my cgi-bin directory, but have none taking me back... so i kind of get "stranded" in my cgi directories when this happens to me, i just disconnect and reconnect again as if it were my first connect of the day and i end up in the home directory and can once again "deal".

So - sorry i'm messing up your release cycle, I do really appreciate you listening to my problems and even doing something about them! peace.

(incidentally, it'd be nice to have a "create empty file" command in this menu too, akin to "create directory", but the duplicate accomplishes this...)

Files > Edit new file ...

When you do one of these, first it spawns a new connection (which i question as the right thing to do, but alas)

If you read the message that is displayed first, you would know, that there is no other way as you use SFTP protocol and it does not have "duplicate" function.

though if you're too "late" it'll have been severed and calling duplicate will (and here i revise my earlier statment) cause WinSCP to report a connection error and reconnect entirely

This was also fixed. At least partially. Now the main connection is kept even if the secondary is diconnected.

in my case, i have symbolic links from my home directory to my cgi-bin directory, but have none taking me back... so i kind of get "stranded" in my cgi directories when this happens to me, i just disconnect and reconnect again as if it were my first connect of the day and i end up in the home directory and can once again "deal".

You can use Remote > Go To > Home Directory function or if it does not work for you, boookmark it (Remote > Add to Bookmarks)

awesome Martin - thanks again. downloading the new version, and check it out - this post is getting long though if there's any more things i'd like to see, i'll start a new topic.

(Topic reuse, only slight offtopic)

Lets say I have readme.txt remote file
I can edit a file directly by doubleclicking it, it will be opened to Notepad text editor. Then I modify file and save it. WinSCP makes it automatically uploading file back to the remote server, it does not ask for confirmation if I _really_ want to upload it back.

Well, this might not be a problem but I now discovered something nasty:
I doubleclick sound.mp3 file and MSMediaPlayer starts playing it, nice and well. But MSPlayer9 actually modifies file somehow after play, and WinSCP starts uploading it in a background.

It was not what I wanted to do, but now it did it. I had to change several filestamps back to history due to some reasons.

Confirmation before uploading edited file or disable auto-upload?
Is one of the mentioned possible now, but I could not find any settings to do so?

asdf wrote:

Is one of the mentioned possible now, but I could not find any settings to do so?

No it is not possible.