How to share file access between two applications?

[David.P]

Hi Forum,

on two PC's on the network I run a (the same) application. That app uses a config sort of file which is updated from time to time, either from the first PC, or from the other.

That file is located on a network drive, so access from each of the two apps is no problem. However, if the file is in use by the app on one PC, the other PC can't read that file (because it's locked), let alone write to it.

What I was wondering, is there any solution to that problem? I mean, like a software that somehow simulates a file that two apps can access at the same time (...or something)?

Thanks already,

Cheers David.P

[Darwin]

Hi David,

I don't have a definitive answer, BUT - backup programs like Genie Backup Manager Pro are able to access files that are in use to back them up. They do this via a plug-in that should work system-wide, I think (I'm actually out of my depth here  ). They've used two systems:

1. Open File Manager
2. File Access Manager

Both of these "solutions" are intended to be used to allow a backup utility to backup up files that are in use, but I am wondering if they might be used to allow you to do what you're after as well...?

[tomos]

could you use two different config files and synchronise them now and again ? -
could be a problem if both change between synchs - the synch programme will copy the most recent and you'll lose the less recent changes
-
is there any app that would "combine" two files?

but really,
it sound like you'd need to talk to  the app developers in order to make a proper job of it...(I think!)

[f0dder]

Sounds like the application keeps the configuration file open as long as the application is running. The application could be reverse-engineered not to keep it open in exclusive mode, but allow read (or even read/write) access from other application. This isn't necessarily a good idea, though - the two app instances will likely end up clobbering eachother's changes.

[David.P]

Thanks everyone for the answers!

Yep, I think the app would have to be re-engineered such that it only reads the file in memory and then leaves it alone (like e.g. notepad). Additionally, the app would have to read the file again first before actually writing to it (in case the other instance would have written to it in the meantime).

Why oh why is there no software (hardware?) solution to that problem? I think that this problem occurs very often. Well of course it could cause all kinds of trouble if used without caution.

The app is btw actually a ISDN caller identifier software, and the to-be-shared file simply is the phonebook that only changes if on either end someone adds a new telephone number entry.   

Cheers David.P

[f0dder]

Yep, I think the app would have to be re-engineered such that it only reads the file in memory and then leaves it alone (like e.g. notepad). Additionally, the app would have to read the file again first before actually writing to it (in case the other instance would have written to it in the meantime).

-David.P (December 09, 2008, 04:44 AM)

That would still leave it vulnerable to a race condition, though...

Why oh why is there no software (hardware?) solution to that problem? I think that this problem occurs very often. Well of course it could cause all kinds of trouble if used without caution.

-David.P (December 09, 2008, 04:44 AM)

The solution is the use of databases, going through a database server instead of directly accessing the files. But of course that is pretty overkill for configuration data

[David.P]

Hmm, actually that adress book seems to be some sort of SQL database...

It consists of the following several files:

phonebook.db
phonebook.db.lck
phonebook.db.log
phonebook.db.script
phonebook.db.properties

of which "phonebook.db.script" contains the lines below:

[Select]

#HSQL Database Engine 1.8.0.9
#Tue Dec 09 20:51:59 CET 2008
hsqldb.script_format=0
runtime.gc_interval=0
sql.enforce_strict_size=false
hsqldb.cache_size_scale=8
readonly=false
hsqldb.nio_data_file=true
hsqldb.cache_scale=14
version=1.8.0
hsqldb.default_table_type=memory
hsqldb.cache_file_scale=1
hsqldb.log_size=200
modified=yes
hsqldb.cache_version=1.7.0
hsqldb.original_version=1.8.0
hsqldb.compatible_version=1.8.0

Would that make any difference to the original question?

David.P

[f0dder]

Does seem like the author tries to keep from having multiple processes accessing the file and causing havok (ie, the .lock file) - but he still keeps the database open during the entire run of the program, which is quite a normal thing to do. To have smooth and painless multiple-processes (especially across networks) accessing a database, you really do need to access it through a database server process, which would be the only process keeping the file open.

[David.P]

Thanks!

Cheers David.P