opening same file twice

[t57042]

I am trying to open the same file 2 times on the same PC (windows XP) to test multiuser possibility.
The fist process seems to lock the file.
The second openfile or readfile returns 0.

Is there a solution to that?

Richard

[t57042]

After further testing the problem only exists when the file is opened with "openfile".
If the file is opened twice with "readfile" both programs can open the file.
I suppose this is the way it is supposed to be.

Is there a way to open with "openfile" without preventing others from opening tat file?

[Kaeru Gaman]

I thought I read a Feature Request for this...
but I can't find it now...

in my eyes it's correct this way, because write-access has to be exclusive.

why don't you use ReadFile if you want shared access?

[edit]
two times write access can produce unpredictable results.
I would suggest a central File-Handler, that grants single write access to the clients.
a client can send a request to the handler and wait for admittance.

[t57042]

I want to try recordlocking - for that the file should be accesible.

[Kaeru Gaman]

hm... still suggesting a central handler.
let the clients send a message to the central handler, the handler itself writes it to disk.

or did I misunderstand now...?

[t57042]

The idea is to use the first byte of each record to indicate if the record is locked.
So before updating a record - read it - check 1st byte - when not locked write.

I used this protocol before in multi user applications (1 computer with several terminals)

[Kaeru Gaman]

do you use a DataBase system?
those should handle this internally...

but ok, having this in mind, it maybe worth a feature request...

[t57042]

This would be to avoid a database system (sqlite locks the entire database = all tables together)

Could this maybe done with an API call?

[Kaeru Gaman]

I would suggest introducing a new flag for OpenFile, like #PB_File_NonExclusive.

[Trond]

The idea is to use the first byte of each record to indicate if the record is locked.
So before updating a record - read it - check 1st byte - when not locked write.

I used this protocol before in multi user applications (1 computer with several terminals)

That won't work. If another application locks the record after the record was read, but before the first byte was checked, there will be havoc.

[mk-soft]

I would suggest introducing a new flag for OpenFile, like #PB_File_NonExclusive.

Yes, I needed too

http://www.purebasic.fr/english/viewtop ... 13&t=41197

[Mahan]

I seem to remember the reason why SQLite has to lock the entire file is that there are OSes where you cannot reliably open a file twice for writing with reliable block-locking. I think this was mainly a Linux issue. And since PB is for Linux too this might be the reason for the limitation?