Hi,
Hopefully someone can help.
We have a process that writes a file using Connect Direct to our local Solaris server and then our C++ program will pick up the file and process it. Unfortunately, because of the size of the file, the C++ program is processing the file before it has finished being written. Which causes digital signature verification to fail.
Does anyone know of a way of ensuring that the process cannot pick up/ access the file before the write is complete? I'm fairly certain that Unix doesn't have any default locking of files.
It is worth noting we do not have GNU on the solaris server.
I have various inelegant solutions (such as listing the directory and checking if the filesize is still changing), but I was wondering if there was a better way.
Thanks in advance
Chris
Thanks, but wouldn't that just check if the open has been successful?
I need to prevent the file being opened until the write from Connect Direct has finished.
Control it from Connect Direct.
Using sysops in process to execute your program after the transfer is completed.
OR
In connect direct process, rename the file after transfer is completed (mv is atomic if on same filesystem), to a name your program expects.
Unfortunately we are using an adaptor and not a full version of Connect Direct (which is what is making life hard).
Well i'm not much of a c++ programer but...
You can check last modification time of file in your code.
So if the file has modification time n seconds/minutes less then systime and the file has not been processed before, execute the program.
Hope that helps
Regards
Peasant.
Clever methods checking timestamps can't tell the difference between a completed upload, a slow upload, a stalled upload, and a broken upload. It's the client application's job to tell you when the file is complete, your server-side one cannot psychically know without its help.
Often this is accomplished by having the application upload to one folder, then having the same application move it to another folder when complete -- as long as the folder is on the same partition, files will seem to 'appear' in it instantly and whole once a download completes, and never before.
The only way to know the file has been completely written is to have the writing process signal success in some way. Because only the writing process knows if it has successfully written all the data supposed to be in the file. The receiving process can not infer that accurately because of failure conditions, so any method based on timestamps or something similar can not be guaranteed to work.
Period.
Renaming the file is probably the best way to do that.
There are some kludges you can use on Solaris using the utssys() call that will return the process IDs of process that have any file open, but that will just tell you the file is open and won't tell you why the process has the file open, nor why it closed it. Look at the "sys/utssys.h" header file.
If you can find the source code for the Solaris "fuser" utility, you can see an example of how to use it.
Or you can run the "fuser" utility in a subprocess using system() or popen().