delete locked file on network

You could do this in your program...

Have an IniFile in the location of the program.  Have your executable at certain intervals look at the ini file to see if it has been modified.  If so read where the new files are.  All the running parts of the app should be in a dll.  The app unloads the dll's, and reloads the new dll's.  The app then attempts to copy the dll's from new location to old location, if successful it updates the ini file in both locations, pointing where the new files are located.

Rick

In general, windows locks all modules that are loaded in memory, because they may have sections that are LoadOnCall to increase performance. The best way would be to query the connections to your network share, query the open files for your app and disconnect these users. Copy your new app over, finished. The broken network connection is resumed by the clients as soon as they access the share again.
BUT if your app was open while you disconnected/copied, any disconnected users' app will just close without warning or notification the time the system tries to load another portion of the apps file (resources etc.).

Slash/d003303

I can't just disconect the user.  That would be bad.  They might become voilent while I could prbably fend off a dozen or so of them they might all group up and ambush me someday.  Like rabid chuahuahs.  I guess I could just have two programs...they run the one and it uses a CreateProcess that starts up the application from whereever I tell it.  Then the user can use the old copy they have loaded and when then logout and restart the app it would load the new program...seams like an easy solution...but I'm still open for some trick entierprise solution to this.  

What about updating the program on the server at a time nobody is using it ? Say, nobody is assumed to use the prog between 2:00 and 3:00 am. If someone just left it up and running, bang 'em out like I mentioned above.
Another thing would be, like you said, create a starter program that reads its settings from the registry or whatever ini file. These settings are updated with the logon script or resist on a public share on the network.

Slash/d003303

Slash/d003303

hup, why did I sign twice ? Time to go home...

Would I need to update the .ini file on login?  The only time the location of the file would change would be when I put a new version out and at that time I could modify the ini file for the loader to point to the new application...am I forgetting something?

Hi d003303,

Could you elaborate more about:

    "query the connections to your network share, query the open files for your app and disconnect these users. "

What are the code (generally) to accomplish these tasks ?

Many thanks,
Itamar

itamar,
you will need the functions

NetServerGetInfo
NetShareGetInfo
NetConnectionEnum
NetSessionDel
NetFileGetInfo
NetFileClose
NetApiBufferFree

They are exported by netapi32.dll in NT and SVRAPI.DLL in Win95.

Slash/d003303

I recommend this simple approach.  Create a simple launch program that copies the EXE on the network to a local directory, then lauch the app from the local directory (possibly C:\WINDOWS\TEMP).  That way you will always have access to the network file for updates and always make sure that the user runs the most updated copy.  You may also want to implement the following:

Provide a check in the main app that requires the launch app to be running.  This will prevent the users from running the mainapp from the network.

Only copy the file from the network to local when the network version is newer.

Provide a check within the main app to let the user know that a newer version is out on the network, so they can restart the app.  This check could be done at intervals or at specific points within your app.

You could be clever and design the launch app to be general purpose by using INI/registry settings.

descikartus

Sound interesting...but I don't like the fact that instead of the application takeing up 5 megs of network drive space it will now take up 125 megs over 25 different computers and this program is scedualed for deployment to over 200 people that would make a gig footprint just for one application.

Out of curiosity do you know how to terminate a process on a 95 machine from another application.  It would be needed to terminate the loading application after the main application has determined that it was loaded correctly.  I am also currious about what your views are on useing the global atom table to control a single instance of the program.

d003303

I've been thinking about your 2-3am solution and I might have a problem.  This would create a maintainence cycle that might fail and leave the program unuseable in the morning...and since these freeking nonprograming type people get to work 3 hours before I do they would try to page me and disturb my early morning cartoon watching.  The updates to this file only come twice a month or so.  I would rather go on-site and run some tests.

I'm thinking that the coolest way would be to write a NT service that handles access to the files but I've never writen a NT service.  The main advantage to this is that I don't have to change my program.

As far as the footprint is concerned, it is trivial considering what a full install on all the local boxes would take up.  Here, you are only copying the code that you plan to update regularly.  All of the remaining code and data can reside on the network.  If your users are not able to put a 5MB file on their machines, then you have bigger problems to solve...

Out of curiosity, are you using run-time packages?  If not, then use them and you will save some space.  This same scheme could be used to update the run-time packages as well.

You can use the Win32 API TerminateProcess, but that requires permission from the process to be terminated and the ProcessID of the application.  I'm researching some other options for you using the WM_QUIT message.

It's not that using 5 megs on each machine would be any problem it just feals like it defeates the purpose of a file server.  Run time packages are cool for intranet apps (ActiveX) that I deploy to thin clients but I don't want the mantainance headache that they become if I used them for an app like this.  I just want it to be super reliable and really fast for me to write.  Granted it would be a better solution for each time they run the application it checks to make sure that they have every thing they need but I would much rather do this with one file than with 20.  I see the advantages It's just that this program is already written and is running.  I still think the clients would be better served with a NT service that could translate client request to the newest version.  Do you have any experiance in writing NT services?

Yo,
I think we are already thinking too complicated. What about this one, it was all mentioned above, now the big picture:
You have a share, say \\server\share. In this share, you have an version.ini file that has one entry, that is a subdirectory of this share. The shares directory structure would be
V1.0
V1.1
V1.2
V1.3
...
Anytime you have a new version, create a directory with a higher version number and change the version.ini file. All you need now is a starter prog that looks at \\server\share\version.ini, looks for the current version and executes \\server\share\V(current}\App.exe. Now the clients get the new version when they terminate your app and start it up again.

Slash/d003303

Sounds good to me 003.  
descikartus - I'm going to Reopen this to grade 003's answer...unfortunatly this means I have to reject yours...
Thanks for all the help - you want to post up an answer there 003.

This is how I'm spawning the application out.  This thing is like 150K it doesn't really need a form does it?  Thanks for all the help.  If anyone feals they need some points I'll open another question to toss some over your way.  I say this because this INI file thing started with RickPet.

procedure TForm1.FormCreate(Sender: TObject);
var
  MyStartInfo : TStartupInfo;
  MyProcessInfo : TProcessInformation;
  MyFile: TextFile;
  FileNameFromFile : String;
begin
  AssignFile(MyFile, 'ServicePlan.ini');
  Reset(MyFile);
  Readln(MyFile, FileNameFromFile);
  CloseFile(MyFile);
  CreateProcess(pchar(FileNameFromFile),
                pchar(FileNameFromFile), nil, nil, False, CREATE_NEW_CONSOLE, nil,
                nil, MyStartInfo, MyProcessInfo);
  Application.ProcessMessages;
  Application.Terminate;
end;

For some reason that CreateProcess doesn't want to load my OCX for my spelling checker.  I'm use a ShellExecute now and it works fine...anyone have any idea why CreateProcess fails with an OLE exception error?

I should add that the create process doens't directly load the spell checker is a part of the exe that the create process calls.
VSSpell