Sending fences.dat file to the hardware terminal is unsuccessfull ("invalid path" error message)

[ArturMalyszewicz]

When trying to send fences.dat file with geofences definition an error is sent with information "invalid path".

Steps to reproduce:

1. Connect to hardware IDP 680 terminal and try to send following message: local message = {SIN = lsfConstants.sins.filesystem, MIN = lsfConstants.mins.write} message.Fields = {{Name="path",Value="/data/svc/geofence/fences.dat"},{Name="offset",Value=0},{Name="flags",Value="Overwrite"},{Name="data",Value="ABIABQAtxsAAAr8gAACcQAAAAfQEagAOAQEALg0QAAK/IAAATiABnAASAgUALjvwAAQesAAAw1AAAJxABCEAEgMFAC4NEAAEZQAAAFfkAABEXAKX"}} gateway.submitForwardMessage(message)
2. An error is reported, fences.dat file is not updated.

[ArturMalyszewicz]

Reported issue not to forget about it. Will check different path.

[afarran]

Where is the error reported (e.g. OTA message, trace output, etc.)? What's the exact error message? I suggested you try a full path with sys:/data/svc/geofence/fences.dat Workaround is to define message using geofence core service to-mobile message

[brabiega]

I've investigated the problem and I've been able to reproduce the issue, it looks like follows: It is not possible to write any data to /data/svc/geofence/fences.dat if geofence service is enabled. After sending following message to filesystem service:

{SIN = 24, MIN = 1, path=/data/svc/geofence/fences.dat, offset = 0, 
flags=Overwrite, data=(some data)

The terminal returns following message:

{SIN=24, MIN=1, path=/data/svc/geofence/fences.dat, offset=0, 
flags=Overwrite, result=InvalidPath}

Listing the /data/svc/geofence dir from CLI:

shell> dir
(Dir)  ---         0  01/01/1980 12:00:00  .
(Dir)  ---         0  01/01/1980 12:00:00  ..
       ---         0  01/01/1980 12:00:00  fences.dat
Found 1 files using a total of 0 bytes.

There is no error message in debug trace:

[    40.041:22:ltrc] [27:INFO] cmd: AT%MGFG="FM161.01",3*FCD6
[    40.318:22:ltrc] [27:INFO] res: \r\n%MGFG: "FM161.01",161.01,0,24,2,120,3,AR0vZGF0YS9zdmMvZ2VvZmVuY2UvZmVuY2VzLmRhdAAAAAFUABIABQAtxsAAAr8gAACcQAAAAfQEagAOAQEALg0QAAK/IAAATiABnAASAgUALjvwAAQesAAAw1AAAJxABCEAEgMFAC4NEAAEZQAAAFfkAABEXAKX\r\n\r\nOK\r\n
[    40.403:22:ltrc] [18:INFO] sending decoded message from transport=1 to SIN=24
[    40.506:22:ltrc] [18:INFO] queuing RL msg #4 (SIN=24, bits=296)
[    40.522:22:ltrc] [18:INFO] sending RL msg #4 trn #1 (SIN=24, bits=296)
[    40.547:22:ltrc] [27:INFO] cmd: AT%MGRT="00000002",3,24,3,AR0vZGF0YS9zdmMvZ2VvZmVu
[    40.659:22:ltrc] [27:INFO] res: \r\nOK\r\n
[    45.644:22:ltrc] [27:INFO] cmd: ATS89?*47C6
[    45.714:22:ltrc] [27:INFO] res: \r\n00004\r\n\r\nOK\r\n
[    45.732:22:ltrc] [27:INFO] cmd: AT%MGRS*04F9
[    45.827:22:ltrc] [27:INFO] res: \r\n%MGRS: "00000002",175.1,3,24,6,37,37\r\n\r\nOK\r\n
[    45.857:22:ltrc] [18:INFO] completed RL msg #4 (SIN=24), status=Success
[    49.180:22:ltrc] [26:INFO] CLI Cmd: [cd data/svc/geofence]

The issue does not occur when geofence service is disabled.

[afarran]

Thanks for the investigation information. I expect the LSF to return an error like "can't write to file" instead of "invalid path". Anyway it looks like this behavior is by design, which is another reason to use standard geofence messages to define geofences in your code as suggested.