Locking a Text FIle

[Jat421]

Hi,

I am looking for a solution for a text file to be locked while it's written to or read from with autoit. Something like this in pearl. I got this from old request. Please help

FILE LOCKING

New function: FileLock
New constants: $LOCK_EX, $LOCK_UN, $LOCK_SH, $LOCK_NB

usage:
$fh = FileOpen("somefile.txt",2)
FileLock($fh,$LOCK_EX) ; lock the file for exclusive use
<write out some text to the file>
FileLock($fh,$LOCK_UN) ; unlock the file
FileClose($fh)

Where:
$LOCK_EX - gives an exclusive lock to the process
$LOCK_UN - releases any previous lock
$LOCK_SH - gives a shared lock (suitable for reading a file)
$LOCK_NB - is a non blocking call, meaning the function will return without waiting for the lock, if the lock isn't immediately available

Edited June 16, 2010 by Jat421

[Thatsgreat2345]

FileOpen should lock it, and you do not need to use any FileLock function to do so.

[trancexx]

FileOpen should lock it, and you do not need to use any FileLock function to do so.

Sharing is sharing, locking is locking. Not to mix.

@Jat421, there is LockFile function available. Very simple call. Try it.

If you fail for some reason, ask again.

edit: ehh...

Edited June 16, 2010 by trancexx

[Jat421]

Sharing is sharing, locking is locking. Not to mix.

@Jat421, there is LockFile function available. Very simple call. Try it.

If you fail for some reason, ask again.

edit: ehh...

Thanks, but I am looking for a function in autoit. I don't have the knowledge to work with the DLL's. Any way it can be done in Autoit? Thanks!

Edited June 16, 2010 by Jat421

[Jat421]

Any other suggestions?

[Thatsgreat2345]

How about learn to use DLLs. He proposed a way and then you ignore it because you don't want to learn and now we should find new ways to help you because you're lazy.... give me a break

[Jat421]

I don't think you know what you are talking about...there a no function in autoit to do that so we are talking about writing a UDF

[MvGulik]

whatever Edited February 7, 2011 by MvGulik

[Jat421]

Basically 50 users will be reading from text file...so when one user is reading the file noone else should have access to it at that time

[Ascend4nt]

This should work, but you'll need a valid file handle returned from 'CreateFile' (not FileOpen). I think there's probably example code somewhere on how to call CreateFile.

; Author: Ascend4nt
Func _LockFile($hFile,$iOffset,$iNumBytes)
    Local $stTemp,$stSplit,$iOffsetLow,$iOffsetHigh,$iNumBytesLow,$iNumBytesHigh
    $stTemp=DllStructCreate("int64")
    $stSplit=DllStructCreate("dword;dword",DllStructGetPtr($stTemp))
    DllStructSetData($stTemp,1,$iOffset)
    $iOffsetLow=DllStructGetData($stSplit,1)
    $iOffsetHigh=DllStructGetData($stSplit,2)
    DllStructSetData($stTemp,1,$iNumBytes)
    $iNumBytesLow=DllStructGetData($stSplit,1)
    $iNumBytesHigh=DllStructGetData($stSplit,2)

    Local $aRet=DllCall("kernel32.dll","bool","LockFile","handle",$hFile,"dword",$iOffsetLow,"dword",$iOffsetHigh,"dword",$iNumBytesLow,"dword",$iNumBytesHigh)
    If @error Then Return SetError(@error,0,False)
    Return $aRet[0]
EndFunc

Note the reason for the structures is because Bit* functions don't work with 64-bit numbers, and if you have a 64-bit number that has the upper bit set, you'd have to do some fancy arithmetic. This way it's just plain simpler.

*edit: code tag, typo, and added author name (me). arggh.. too much on the mind

*2nd edit: $iNumBytesHigh used the wrong DLLStruct* call. oops!

Edited June 19, 2010 by Ascend4nt

[Jat421]

Thanks a lot!!!...I will give this a try!!!

[Thatsgreat2345]

I don't think you know what you are talking about...there a no function in autoit to do that so we are talking about writing a UDF

I know exactly what I'm talking about, I'm calling you a lazy fvck that doesn't have any drive to learn but merely wants everything handed to him.

[Jat421]

I know exactly what I'm talking about, I'm calling you a lazy fvck that doesn't have any drive to learn but merely wants everything handed to him.

Thatsgreat2345, Thank you so much for your contribution in this thread lol.

[MvGulik]

whatever Edited February 7, 2011 by MvGulik

[Ascend4nt]

MvGulik,

An error in the logic here:

"If $i64 < 0x80000000" will ring true only if $i64 is <= -2147483649. AutoIT always converts literal 0x80000000 into a negative number. (-2147483648 in this case)

Also:

$iLow32 = Number(String(DllStructGetData($t32, 1))) ;; forced int32 type.
    $iHigh32 = Number(String(DllStructGetData($t32, 2))) ;; ...

What's the point of converting DLLStructGetData() on a dword variable (32-bit integer) to a string and then a number? That makes no sense to me.

oh... I see what you're doing - VarGetType() returns int64. That's kind of odd. Nonetheless, the internal variable type doesn't matter - the data size doesn't exceed 32-bits when it is pulled. But I guess if you like to be concerned with internal variable types..

One more problem though - if something is <0 it does not mean that all upper 32 bits are set (you set $iHigh32 to -1, which is wrong). Negative numbers have the same 63-bit range as positive numbers, so the upper 32 bits can vary wildly.

The function _LockFile of course shouldn't be called with negative numbers, and more than likely won't have the high bit set anytime far into the future (the high bit of course indicating a negative number in AutoIT). Haha, could you imagine a file (or disk for that matter) supporting files of size 9 quintillion bytes?

Oh, but the Mod() and Floor() usage is interesting, and does seem to work - but you need to jump through hoops there, plus all in all everything takes more time and space then a few lines to create structures and grab data from them.

The real problem here is AutoIt's Bit* functions and the 64-bit signed number problem. If Bit* operations didn't force operations to be signed, and didn't just work on 32-bit numbers (even in today's world of 64-bit code:blink: ), we could easily use them instead. Of course, those Bit* functions are and probably always will be signed functions, which means workarounds would still be needed.

[Jat421]

Honestly, this is all over my head. I would love to learn more from you guys. Any good place I can start to learn with DLL's. And really appricate your help with this. Thanks!

Ascend4nt I checked out your website. You have some great stuff on there. Wondering if you have any tutorials for the UDF's you created. Thanks!

Edited June 18, 2010 by Jat421

[Ascend4nt]

Jat, to be honest, everyone starts coding in AutoIT without knowing a heckuva lot about the advanced features - even the experts here started out as clueless as everyone else (look back through post histories). And yah - that includes me

Just like any language, you learn as you go. I'm not sure if anyone has tutorials on AutoIT as a language, but syntax is close to a number of other languages - and the Help file does give you a lot of good info. DLL* stuff is one unique feature that is confusing to most people though.

There's plenty of examples on the website of its use, but what might help you understand it is a tutorial Monoceres did on it. I haven't looked into it personally, but it seems to have helped a number of people understand what it all is about.

*edit: check KaFu's excellent collection of links (specifically the 'Tutorials' section) in his signature (or his about me page).

Edited June 18, 2010 by Ascend4nt

[Jat421]

Jat, to be honest, everyone starts coding in AutoIT without knowing a heckuva lot about the advanced features - even the experts here started out as clueless as everyone else (look back through post histories). And yah - that includes me

Just like any language, you learn as you go. I'm not sure if anyone has tutorials on AutoIT as a language, but syntax is close to a number of other languages - and the Help file does give you a lot of good info. DLL* stuff is one unique feature that is confusing to most people though.

There's plenty of examples on the website of its use, but what might help you understand it is a tutorial Monoceres did on it. I haven't looked into it personally, but it seems to have helped a number of people understand what it all is about.

*edit: check KaFu's excellent collection of links (specifically the 'Tutorials' section) in his signature (or his about me page).

wow that's great, after actually reading the PDF I understood bits of that code now. Thank you so much. I had no idea that most of the autoit interface related functions are actaully calling windows functions by DllCall. Nice!!

[MvGulik]

whatever Edited February 7, 2011 by MvGulik

[Ascend4nt]

I fail to see what the supposed logical error is I made in your view?

$i64 < 0x80000000

That part of the logic made no sense to me.. I was looking at that as 'why does anything less than -2147483648 make that part of the code special'?. But after some thought I think I see what you were after - you want to isolate cases where all upper 32-bits would be set, yes? (which would make the upper 32-bits equivalent to -1).

If that's the case, you'd want to compare against -4294967296. (i.e. change it to $i64 < -4294967296). Anything below that value will have the upper bits altered.

I'm not getting what parts you are seeing as hoops in this case?

You used "Int()' twice, then have this code:

If $iLow32 < 0 Then $iLow32 = Int('0x' & Hex($iLow32, 8)) ;; negative, strip leading int64 FF's.
    If $iHigh32 < 0 Then $iHigh32 = Int('0x' & Hex($iHigh32, 8)) ;; ...

So you have the two Int() conversions, the 'If' checks, Hex() conversion with string concatenation, and Int() again. I'm not saying this is bad - its just more work than a simple set/get from a dllstruct.

Oh.. and also, Int() on a 64-bit number with the high-bit set will return the wrong value. (but I believe we covered that)

*edit - word missing

Edited June 19, 2010 by Ascend4nt