Reading a file .db

[Adams]

With Autoit 3.3.12.0 a script like the one attached was reading the file "sync_config.db" of google drive, located at %LOCALAPPDATA%\Google\Drive returning into var $sCloudFolder the value "C:\Users\Adams\Google Drive".
Now, with Autoit 3.3.14.1, the same script, reading the same file, return into var a long string of characters.
I made a text version of the file using copy and paste to observe the correct behavior.
I think that the cause is the new method of decoding, but I could not figure out how to solve.

expandcollapse popup

#include-once
    #include <FileConstants.au3>
    #include <Constants.au3>

    ; if the Google Drive configuration file exists, it is read
    If FileExists("sync_config.db") Then
        ; open the Google Drive configuration file in reading
        $Handle_GoogleDrive_R = FileOpen("sync_config.db", $FO_READ)

        If $Handle_GoogleDrive_R = -1 Then ; Check if file opened for reading OK
            MsgBox(0, "Error", "An error occurred when reading the file " & "sync_config.db")
            Exit
        EndIf



        ; reading Google Drive configuration file
        $File_GoogleDrive = FileRead($Handle_GoogleDrive_R)

        ConsoleWrite("$File_GoogleDrive = " & $File_GoogleDrive & @CR)

        ; find folder path initial position
        $Start = 1
        $Find = "local_sync_root_pathvalue\\?\"
        $Result = StringInStr($File_GoogleDrive, $Find, 0, 1, $Start)

        ; find folder path final position
        $Start = $Result + 29
        $Find = ""
        $Result = StringInStr($File_GoogleDrive, $Find, 0, 1, $Start)
        $Len = $Result - $Start

        ; folder for Google Drive Service
        $sCloudFolder = StringMid($File_GoogleDrive, $Start, $Len)

        ConsoleWrite("$sCloudFolder = " & $sCloudFolder & @CR)

        ; close Google Drive configuration file
        FileClose($Handle_GoogleDrive_R)
    EndIf

 

sync_config_original.db

sync_config_copy.db

[Celtic88]

#include <SQLite.au3>
#include <Array.au3>

_SQLite_Startup()
_SQLite_Open(@ScriptDir & "\sync_config_original.db")
Local $hQuery, $aRow, $Arraydb[1][3]
_SQLite_Query(-1, "SELECT * FROM data;", $hQuery)
While _SQLite_FetchData($hQuery, $aRow, False, False) = $SQLITE_OK
    $Arraydb[0][0] += 1
    ReDim $Arraydb[$Arraydb[0][0] + 1][3]
    $Arraydb[$Arraydb[0][0]][0] = $aRow[0]
    $Arraydb[$Arraydb[0][0]][1] = $aRow[1]
    $Arraydb[$Arraydb[0][0]][2] = $aRow[2]
    If $aRow[0] = "feature_switch" Or $aRow[0] = "tango_storage" Then $Arraydb[$Arraydb[0][0]][2] = _base64decode($aRow[2])
WEnd
_SQLite_QueryFinalize($hQuery)
_SQLite_Close()
_SQLite_Shutdown()

_ArrayDisplay($Arraydb)

Func _base64decode($sb64string)
    Local $a_call = DllCall("Crypt32.dll", "bool", "CryptStringToBinaryA", "str", $sb64string, "dword", 0, "dword", 1, "ptr", 0, "dword*", 0, "ptr", 0, "ptr", 0)
    If @error Or Not $a_call[0] Then Return SetError(1, 0, "")
    Local $a = DllStructCreate("byte[" & $a_call[5] & "]")
    $a_call = DllCall("Crypt32.dll", "bool", "CryptStringToBinaryA", "str", $sb64string, "dword", 0, "dword", 1, "struct*", $a, "dword*", $a_call[5], "ptr", 0, "ptr", 0)
    If @error Or Not $a_call[0] Then Return SetError(2, 0, "")
    Return DllStructGetData($a, 1)
EndFunc   ;==>_base64decode

[jchd]

You probably shouldn't post actual private data like this. Anyway, this file is an SQLite database, which you can open and query with a lot of external tools (try SQLite Expert freeware for example), the SQLite command-line tools (sqlite.exe) or even with your own AutoIt code (SQLite UDF is included in the standard distribution) **.

There is zero chance you can reliably extract anything from this king of file by simply using FileRead nor any other "flat" file function.

** [like Celtic88 just did]

Edited September 2, 2015 by jchd

[Adams]

Thankyou Celtic88. Ok, your solution working but the approach is more different. And thankyou jchd but you say "There is zero chance" with autoit 3.3.14.1? Because with 3.3.12.0 I was able to read this file using FileRead. The question is: what is changed?

[Adams]

Eureka . I used $FO_UTF16_LE + $FO_ANSI in FileOpen and now the script works. I tried all different "mode" to open the file but had not thought to mix two.

expandcollapse popup

#include-once
    #include <FileConstants.au3>
    #include <Constants.au3>

    ; if the Google Drive configuration file exists, it is read
    If FileExists("sync_config.db") Then
        ; open the Google Drive configuration file in reading
        $Handle_GoogleDrive_R = FileOpen("sync_config.db", $FO_UTF16_LE + $FO_ANSI)

        If $Handle_GoogleDrive_R = -1 Then ; Check if file opened for reading OK
            MsgBox(0, "Error", "An error occurred when reading the file " & "sync_config.db")
            Exit
        EndIf

        ; reading Google Drive configuration file
        $File_GoogleDrive = FileRead($Handle_GoogleDrive_R)

        ConsoleWrite("$File_GoogleDrive = " & $File_GoogleDrive & @CR)

        ; find folder path initial position
        $Start = 1
        $Find = "local_sync_root_pathvalue\\?\"
        $Result = StringInStr($File_GoogleDrive, $Find, 0, 1, $Start)

        ; find folder path final position
        $Start = $Result + 29
        $Find = ""
        $Result = StringInStr($File_GoogleDrive, $Find, 0, 1, $Start)
        $Len = $Result - $Start

        ; folder for Google Drive Service
        $sCloudFolder = StringMid($File_GoogleDrive, $Start, $Len)

        ConsoleWrite("$sCloudFolder = " & $sCloudFolder & @CR)

        ; close Google Drive configuration file
        FileClose($Handle_GoogleDrive_R)
    EndIf

 

Edited September 3, 2015 by Adams

[jchd]

This is utterly ridiculous.

And please don't quote only part of my phrases: I said "There is zero chance you can reliably extract anything from this king of file by simply using FileRead nor any other "flat" file function."

[Adams]

This is utterly ridiculous.

And please don't quote only part of my phrases: I said "There is zero chance you can reliably extract anything from this king of file by simply using FileRead nor any other "flat" file function."

Why do you say that? I read the file and extract the information I needed. And I'm sorry for the partial quote of your intervention but I wanted to take your sentence to ask if you mean that there were no possibilities with version 3.3.14.1.

[jchd]

Why? Because it's true!

You insist on reading an SQLite database as if it was a text file and this is definitely wrong. Use the right tool for that task and stop messing with unreliable ways. It has nothing to do with what AutoIt version you use, even with which language you use to read and "extract" data from the database. If you really need to check by yourself I provide you with a valid SQLite database containing the actual data your file contains (from the SQLite point of view) but from which you won't extract the correct information with your "flat file" read approach.

 

sync_config1.db

[Adams]

Why? Because it's true!

You insist on reading an SQLite database as if it was a text file and this is definitely wrong. Use the right tool for that task and stop messing with unreliable ways. It has nothing to do with what AutoIt version you use, even with which language you use to read and "extract" data from the database. If you really need to check by yourself I provide you with a valid SQLite database containing the actual data your file contains (from the SQLite point of view) but from which you won't extract the correct information with your "flat file" read approach.

 

sync_config1.db

Of course, I agree that to read a sql file, my approach is not the most appropriate. But for what it takes to me and to read "my" file (and not others) the method worked. Thanks for the advice anyway: if I read another  SQLite database with more complex needs I will use the most appropriate method.

[guinness]

my approach is not the most appropriate

Correction, that should be "my approach is totally wrong". I agree with @jchd on this one. 

Edited September 13, 2015 by guinness
Typo

[Adams]

Correct, that should be "my approach is totally wrong". I agree with @jchd on this one. 

Ok

Cloud Folders.Exe

[guinness]

I don't download executables from untrusted sources.

[jchd]

Adams,

Your "method" will work as long as the sequence of updates in the database leaves the row you're after in the same place. And I bet my keyboard that you don't have control over how "your" DB will evolve since it isn't really yours: it's managed by Google, not you. Google may have to change things a lot over time and you'll be reading the very same free page in the DB while the actual correct data will reside elsewhere. Said otherwise, this is utterly unreliable and you don't have the faintest clue as to when it will silently fall apart.

[Jos]

@jchd,  

Not sure I've seen you this  persistent before.  Please watch your blood pressure and when he doesn't get it by now it surely is a lost case... But it is his case.  ;-) 

Jos

[jchd]

I found it interesting to see how deep wrong ideas can grow their roots. As you say you and me don't care since we're not the ones who shall hit bricks at full speed.

[Skysnake]

@jchd, I respect your opinion. I follow many of the topics you post on for your insightful commentary.  I made a mental note of your response on this one.  Thought that its easy to find a quick and dirty fix that will turn into a disaster later.  I agree with advice by @Jos.