Sign in to follow this  
Followers 0
Jat421

Locking a Text FIle

40 posts in this topic

#1 ·  Posted (edited)

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 by Jat421

Share this post


Link to post
Share on other sites



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

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

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 by trancexx

♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

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 by Jat421

Share this post


Link to post
Share on other sites

Any other suggestions?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

#8 ·  Posted (edited)

whatever Edited by MvGulik

"Straight_and_Crooked_Thinking" : A "classic guide to ferreting out untruths, half-truths, and other distortions of facts in political and social discussions."
"The Secrets of Quantum Physics" : New and excellent 2 part documentary on Quantum Physics by Jim Al-Khalili. (Dec 2014)

"Believing what you know ain't so" ...

Knock Knock ...
 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

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 by Ascend4nt

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

#14 ·  Posted (edited)

whatever Edited by MvGulik

"Straight_and_Crooked_Thinking" : A "classic guide to ferreting out untruths, half-truths, and other distortions of facts in political and social discussions."
"The Secrets of Quantum Physics" : New and excellent 2 part documentary on Quantum Physics by Jim Al-Khalili. (Dec 2014)

"Believing what you know ain't so" ...

Knock Knock ...
 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

#16 ·  Posted (edited)

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 by Jat421

Share this post


Link to post
Share on other sites

#17 ·  Posted (edited)

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 by Ascend4nt

Share this post


Link to post
Share on other sites

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!!

Share this post


Link to post
Share on other sites

#19 ·  Posted (edited)

whatever Edited by MvGulik

"Straight_and_Crooked_Thinking" : A "classic guide to ferreting out untruths, half-truths, and other distortions of facts in political and social discussions."
"The Secrets of Quantum Physics" : New and excellent 2 part documentary on Quantum Physics by Jim Al-Khalili. (Dec 2014)

"Believing what you know ain't so" ...

Knock Knock ...
 

Share this post


Link to post
Share on other sites

#20 ·  Posted (edited)

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 by Ascend4nt

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0