Data Security Product conflict with INIWRITE function

[mojomatt]

OK here's an odd one... I have installed a data security product called Vormetric on my Windows 2008R2 server and afterward the iniwrite function no longer works.  If I uninstall it then iniwrite once agains functions as expected.  Interestingly enough Fileopen and Filewrite work regardless of whether or not Vormetric is installed.  Does anyone have any idea what the INIWRITE function is doing behind the scenes?  That may help me understand why Vormetric is stopping it from working.  Below is a test script I use to verify functionality.

 Thanks in advance for any help you can offer.

 

$strTemp1 = "test text"
$strTemp2 = "test text 2"
$hdlFile = FileOpen("C:\test.txt",2)

$strTemp = FileWrite($hdlFile,$strTemp1)
MsgBox(0,"",$strTemp) ;shows a 1 which means success

$strTemp = FileClose($hdlFile)
MsgBox(0,"",$strTemp) ;shows a 1 which means success

$strTemp = IniWrite("C:\test.txt", "Section1", "Value", $strTemp2 )
MsgBox(0,"",$strTemp) ;shows a 0 which means failure

 

[Jos]

It is using the standard window API: WritePrivateProfileString

Jos

[mojomatt]

Thank for the quick reply Jos.  Ok so when I call the api directly it still doesn't work on my server with Vormetric installed.  The code below does work on a server without Vormetric.  Interestingly enough it will create the .ini file if it doesn't exist but it won't write anything in the file.  I'll likely have to call the fine folks at Vormetric to get to the bottom of this unless anyone else has any ideas.

 

 

#include <Array.au3>
$arrTemp = DllCall("kernel32.dll", "int", "WritePrivateProfileString", "str", "Section1","str","Value","str","Value1","str","c:\test.ini")
_ArrayDisplay($arrTemp)

 

[JohnOne]

Do they work with #RequireAdmin.

[mojomatt]

#RequireAdmin makes no difference.

Edited August 12, 2015 by mojomatt
formatting

[iamtheky]

how about on a file that is not in the root of c:\  ?

[JohnOne]

And try FileWrite without FileOpen, does thAT WORK?

[mojomatt]

 I've tried writing to an .ini file in different locations without success.

Filewrite by itself works as it should.

When I use the _WinAPI_GetLastError ( ) function after the iniwrite attempt I get an error 33 which is "The process cannot access the file because another process has locked a portion of the file."  I've confirmed this while using Process Monitor which shows the file creation as successful but the filewrite operation fails.

My guess is that the iniwrite/WritePrivateProfileString functions create a file, write to the file, and try to save the file in 1 operation and in the middle of this sequence Vormetric is getting involved and locking the file.  It's still confusing because I'd guess that is the same sequence that Filewrite is doing.

Oh well I'll see what Vormetric has to say about this.

Thanks all for your help.

 

[EmilyLove]

And try FileWrite without FileOpen, does thAT WORK?

You cannot FileWrite() without first obtaining a handle via FileOpen().

 I've tried writing to an .ini file in different locations without success.

Filewrite by itself works as it should.

When I use the _WinAPI_GetLastError ( ) function after the iniwrite attempt I get an error 33 which is "The process cannot access the file because another process has locked a portion of the file."  I've confirmed this while using Process Monitor which shows the file creation as successful but the filewrite operation fails.

My guess is that the iniwrite/WritePrivateProfileString functions create a file, write to the file, and try to save the file in 1 operation and in the middle of this sequence Vormetric is getting involved and locking the file.  It's still confusing because I'd guess that is the same sequence that Filewrite is doing.

Oh well I'll see what Vormetric has to say about this.

Thanks all for your help.

 

I would contact Vormetric as well. You mentioned in your OP that it is a Data Security software. Have you tired whitelisting (adding an exception) to the directory of the ini file you are trying to write?

[JohnOne]

You cannot FileWrite() without first obtaining a handle via FileOpen().

I think you will find, that you can.

[EmilyLove]

I think you will find, that you can.

The documentations says otherwise.

https://www.autoitscript.com/autoit3/docs/functions/FileWrite.htm

"Write text/data to the end of a previously opened file."

Remarks

The file must be opened in write mode or the FileWrite() command will fail.

 

Edited August 12, 2015 by BetaLeaf

[JohnOne]

There is no mention that the OP needs to append data.

[EmilyLove]

There is no mention that the OP needs to append data.

I literally copy-paste from the documentation. Idk why it says "to the end" when it can write in several different modes. Another case where the documentation is out of date. For starters, FileOpen() is what sets the Read/Write mode, so it is false to assume that Append was used automatically, like it was in the documentation.

Edited August 12, 2015 by BetaLeaf

[kylomas]

Betaleaf - from the Help file for FileWrite...

The handle of a file, as returned by a previous call to FileOpen(). Alternatively, you may use a string filename as the first parameter

I agree there is some inconsistency. 

Edited August 13, 2015 by kylomas

[BrewManNH]

There's no inconsistency, it's just written poorly. It is trying to say; if you use a file handle on a file that was opened in read only mode it will fail if you try to write to it.

It also clearly states this in the help file:

If a filename is given rather than a file handle, the file will be opened and closed during the function call. For parsing large text files this will be much slower than using filehandles. However, filename will be created if it does not already exist.

[JohnOne]

I would also go as far as to say that it would only be "much slower" if the file is being parsed in a loop.

I imagine FileOpen, FileRead, FileClose for the whole contents is the same as FileRead alone.

Edited August 13, 2015 by JohnOne