SOTI Pulse Logo

File Corruption Using File Sync

JJ
Jim J
Delta Air Lines, Inc.

Hello All, 

I wanted to throw this out here:

For Zebra upgrades and patches I use Filesync Rules to send the massive files down to the device. What I have found is that in some cases the file size is correct, but the file is corrupt. I attribute this to the fact that I have a lot of locations that have marginal network coverage at night due to massive concrete and steel (cell) or very limited ethernet bandwidth. 

In any case I have files that end up on the device that are corrupt. I have resorted to remoting into each of these devices that don't successfully update and performing a md5sum command on the file downloaded file to determine whether it is corrupt or not. If it is corrupt, I delete the file and allow the device to attempt to download it again using the file sync rules. 

My question is whether there is any way to automate this process as part of the file sync rule scripting. Under v14.1 I didn't see a way. I am working on an upgrade to v15.3 but am not there yet. 

Personally, I wish that SOTI was smart enough to validate that the files that were sync'd were good without any intervention. Any ideas or sample scripts that anyone is willing to share?

Thanks. 

Jim

file-sync android-scripting
4 years ago
Android
ANSWERS
J
JCMOD@SOTI
4 years ago

Hi Jim,

Thank you for posting in SOTI Central,

We've made improvements within V15 regarding our File Synchronization feature. Have you managed to obtain a v15.3 test environment to see the difference in behavior between production and test? Also to note, feel free to raise a Support Case through support@soti.net and we'll be happy to look at any issues you're facing and ultimately aim to resolve them.

Regards,

RC
Raymond Chan Diamond Contributor
4 years ago

Hi Jim,

How big was the file you are talking about? Was the device rebooted and/or powered off one/many times before the big file was completely  synchronized.

I am not from Soti, but I strongly believe that some kind of hashing as well as packet-level CRC have been included to verfiy integrity of sychronized files for many years, as I personal have not experienced or heard from any of my customers about similar synchronization error problem in the last ten years.    However, there might be bug(s) related to hashing when support for sychronizing larger files were recently added, or only in particular server/device-agent version(s).

So, instead of making a feature request,  I think you should open an official support ticket, giving them details about the sychronization set-up (file size, whether file has be rebooted/powered-off, agent version, file-sync rule options used, server/agent versions, etc.), so that they can locate which part(s) of their current implementation have bug(s).  This can likely benefit other MobiControl users who are using file-synchronization with similar buggy implementation(s) but are not aware of the data corruption risk.

Similar Discussions