Feature request: more communication from Remote Service

[syncing_feeling]

Greetings,

I am a big fan of SFFS. I am using 5.21b and Remote Service 5.20.

I have a feature request. Occasionally something will go wrong with a request sent to the Remote Service and it would be great if the Remote Service could communicate more info to the desktop software in those instances so that the desktop software spends less time waiting when there is an error at the remote location.

A recent example is some MD5 checksum requests that could not be opened and gave the following error:

Checksumming exception: A: Cannot open file

After a number of tries the Remote Service deletes the file, but if I manually copy it back to the original location the Remote Service then opens it fine. The problem is intermittent, and there is no discernible pattern. It was happening when I was running a profile with Binary Compare enabled (and using the Remote Service for checksums on the Right side, which is the destination). This is the first time I have run this. My intention is to periodically run my offsite profiles with Binary Compare turned on as a way to check that files at the destination are still correct (ie, to make sure no data corruption has somehow happened). In this instance, not every checksum request produced an error; it would process several fine and then throw an error on several.

I don't mind so much that the Remote Service encounters errors occasionally, but my request is that it be able to communicate more with the SFFS desktop software. So for example, if the Remote Service encounters some kind of error (such as the above) and is not able to process a command for whatever reason, it would be great if it could send a command back to the SFFS desktop software notifying it of that. Then the desktop software could take appropriate action (in this case re-send the checksum request). Currently the SFFS desktop software will just wait and wait (and most likely eventually time out), but if the Remote Service could communicate more with the desktop software that could greatly reduce the waiting.

Thank you much for your consideration!

[syncing_feeling]

Any chance of improving communication from Remote Service as described above? If not (or if yes, but it will be a while before the improvements can be implemented), I'd greatly appreciate some help with the problem described above. I'd really like to do a run of all my offsite backups with Binary Compare enabled, but because the Remote Service intermittently has trouble with opening the checksum requests it makes doing this impractical. Any help would be greatly appreciated (and I'd still love to see the above request improvements too! ).

Thanks in advance!

[superflexible]

OK I will improve this and hopefully get a more detailed error message.

[syncing_feeling]

Okay, that would be great. Then I can do more troubleshooting on my end.

Thanks!

[superflexible]

Hello,

I found that the ExtremeSync Remote Service Control Panel does show more information than just "Cannot open file". It shows the filename that can't be opened as well as the exact error message, which could be "Access denied" or something like that.

This problem has never occurred before. Unfortunately reporting it back to the main program is not feasible very soon.

[syncing_feeling]

Hi,

Thanks for the update. Yes, I know that it will show the filename. I don't think there was any other error visible though or I would have posted that (I'm usually pretty good about that kind of thing). Now I will say that I have noticed that in my Remote Service installation that sometimes not all of the message is visible because other messages push it down out of view (and there is no way to scroll in order to read previous messages), so it is possible that it is saying more in my case but I cannot see it.

Regardless, do you have any ideas why it is running into trouble opening the checksum request files, but only sometimes? The files that the checksum requests are for are very small and so the requests are being sent quickly (as they are being processed quickly, except for when the Remote Service can't open the checksum request file). I had wondered if perhaps things were happening so quickly that the local SFFS wasn't releasing the request file quickly enough or something. I tried setting the Remote Service check interval to longer (eg, several seconds), but that did not seem to have an effect.

I have noticed on these occasions that even with the checksum request files that the Remote Service is able to open, it is not always able to open them on the first try. So there is some kind of temporary hold or something happening where the Remote Service is not able to access the file, but after several tries it sometimes IS able to.

All of this only happens (so far as I know) when running a binary compare backup. My regular backups seem to run fine (to my knowledge). For example, remote listing request files are opened fine. All of these backups are over a vpn connection that makes the remote locations available via Windows Explorer in the local computer.

I understand that making the Remote Service communicate more to the main program is not feasible very soon. I know you have to set priorities and I respect that. Nonetheless, any help you can give me in troubleshooting the above problem would be greatly appreciated!

Thanks in advance!

[superflexible]

How does the main program connect, VPN, FTP, ... ?

[superflexible]

OK as a first step, I will have the Remote Service write the error to a log file, so at least we know what the error is.

[superflexible]

I just saw that uploading the request file does not use a temp name, so if the upload takes longer than the Remote Service retries accessing the file, it may fail. I will fix this in 5.35rc3 today.