[RESOLVED] Run into "chicken & egg" problem. Workaround?

[stanav]

Hello all,
I'm working on an application which when starts up, it'll read a config file which resides on a network share. However, the application does not know where this file is until it reads the contents of that file for the first time (then it save the file path for subsequence runs). The bad part is that this file can be moved from one server to another server, and everytime the file is moved, its contents is automatically changed to show where it currently is without human intervention.

So it's like the famous "chicken and egg" problem. To read the file, I must know where it is, but I can not tell where it is until I read it.

What I'm doing currently is to use another file (which is manually edited to record the current location of the config file) at a fixed location, and when the application starts up, if it can not find the config file from the path saved in My.Settings, it'll go to the fixed location file to get the correct path, read the config file, update My.Settings for the next run. This works, but it requires human intervention to edit the file at the fixed location, which can be out of sync at times (for example, on weekends, no one's at work to go in the file and change it should the config file get moved). And yes, I have no control over the application that moves the config file (it's a third party application not developed in house).

I'm open for any better ideas....
Thank you.

[NickThissen]

Just throwing some idea's here, but could you not prompt the user to select the file when it's not found? Provided the users are aware of this file which obviously doesn't need to be the case...

[dbasnett]

how does the third party application know where it is. it must be keeping the current location somewhere.

[TCarter]

Why not have the file location in a text file or in a database on a web server and have the program read from it?

[Hamish]

If you're running a Windows file server you could just have the application point to a DFS link. All you have to do when you move the file is modify the DFS link to point to it's new location.

[Shaggy Hiker]

Is the file always in a predictable place on whichever server it happens to reside on?

[noahssite]

Why not have the file location in a text file or in a database on a web server and have the program read from it?

I would go with what TCarter is saying.

The file on the server as you said contains the file path. Whenever it is moved it updates the file path in the file... As well as updating the variable in the file you can also update the database / other file on a server, like what TCarter was saying.

[dbasnett]

from the OP "And yes, I have no control over the application that moves the config file (it's a third party application not developed in house)"

[stanav]

@TCarter: the config file is created and maintained by a thrid party application which I do not have control over. If I put that file to a known fixed location, it will break the that application. So what I've already done is pretty much as your suggestion: using a 2nd file at a known fixed location to store where the 1st file is.... On the 3rd party application, it always shows the users where the config file currently is, so should a change occurs to its current location, the user will go into the 2nd file and update it to match the new location.

@Shaggy: yes, the file will always be in a certain folder (name), just at different servers.

As I'm writing this reply, an idea came in mind: using a FileSystemWatcher (running as a service) to watch that config file and update the 2nd fixed file when the config file is moved, then reset the FSW.Path property to the new path... I think this will work.

[Shaggy Hiker]

That's where I was headed, too. I was thinking of a "File Hunter" program that would look for the file periodically and if it was no longer in folder X, then go looking in the other possible folders. That program could then publish some event or message that other programs could listen for so that they could update their references as needed. Alternatively, the File Hunter could be queried for the current information.

[Half]

You can hook the 2nd application and use a callback to yours when moving the file. Read the memory with the new path or something.

Also Windows history keeps logs when a file is opened, closed, moved, deleted. To an extent it is like a logger. Not sure if it is logging non user actions but probably yes.

[TCarter]

@TCarter: the config file is created and maintained by a thrid party application which I do not have control over. If I put that file to a known fixed location, it will break the that application. So what I've already done is pretty much as your suggestion: using a 2nd file at a known fixed location to store where the 1st file is.... On the 3rd party application, it always shows the users where the config file currently is, so should a change occurs to its current location, the user will go into the 2nd file and update it to match the new location.

@Shaggy: yes, the file will always be in a certain folder (name), just at different servers.

As I'm writing this reply, an idea came in mind: using a FileSystemWatcher (running as a service) to watch that config file and update the 2nd fixed file when the config file is moved, then reset the FSW.Path property to the new path... I think this will work.

so, to my understanding is this.

The program needs to read from a default config file just to load, but will then load the users(3rd parties) config file from there on out. Correct?

Why not make a setting, set the default value to a generic run of the mill config file on some web space. so upon the first initial load, it will get the default config file. Then they can modify it in program to their liking. Then set the program to read from it from there on out.

[stanav]

so, to my understanding is this.

The program needs to read from a default config file just to load, but will then load the users(3rd parties) config file from there on out. Correct?

Why not make a setting, set the default value to a generic run of the mill config file on some web space. so upon the first initial load, it will get the default config file. Then they can modify it in program to their liking. Then set the program to read from it from there on out.

That is what I'm already doing... On start up, the program will read a file at a fixed location to get the current path to the config file and once it knows where the config file is, it just go there and reads the config file. The config file itself also stores the current path, so what I'd like to do is to read that information directly from the config file instead of reading it from a 2nd file. However, like I said, I can not read a file when I don't know where it is, and in order for me to find out where that file is, I must read its contents first. Using a 2nd file is the workaround, but the 2nd file may not get updated in time since it was edited manually. Now I'm using a FSW object to follow the config file and update the 2nd file, and it seems to solve the problem. So I just go ahead and mark this thread as resolved.

Thank you every one for your valuable suggestions.

[dbasnett]

Wtg!