I am writing some code to update an application by fetching new dlls from an ftp site, according to a manifest file, also at the ftp site, which specifies the versions of each dll. The basic idea is, that an updater program runs at startup, which checks the manifest at the ftp site, downloads any dll’s which are newer than those currently used by the application, and then starts the application and shuts itself down.
This leads to the following problem, that I am not sure of the best way to handle: Say that I want to put a new dll on the ftp site, but at the same time an updater application instance tries to read that dll. If I delete the dll, and then copy over the new one, the updater might not see the file, even though the manifest says that it should be there.
I have the idea of a sort of marker file, that will act as a synchronization object, and whose existence I and the updater instance can use as a lock, but is that not just moving the problem? There is still the time between checking if the lock is there, and making the lock, in which someone else could make the lock, and start modifying the ftp files. Plus, if some updater crashes before deleting the marker, there is no way of telling, whether the leftover marker should be deleted.
Edit: I also saw a suggestion to upload the files to another folder, and then rename the folder, since renames are supposed to be an atomic operation in ftp, but is it possible to just rename the folder to the name of an existing folder? Shouldn’t the existing folder be deleted first, thus causing the same problem?
Is there a standard approach to solve this?
How about this: On the FTP server, include version info in the filename. On the client, rename the file after downloading.