-
dfQ creator
A couple of questions, Howard
I'm working on updating dfQ so that it will work for Phase II, and I've got a couple of questions. As a reminder dfQ is primarily intended for no-netting. That is it automates the uploading process from clients that have no internet access (but are (indirectly) connected to another computer which does).
Here's where the question I posed to you a while back about separating the functionality of listing files to upload and saving extra information, instead of saving it all in filelist.txt has come back to haunt me, I think.
Specifically in terms of uploading files. Traditionally, it's been ok to go ahead and upload the .val and .log files along with the filelist.txt. In terms of the behavior on the client, all of these files could be transferred together to another computer and uploaded from there. Once the files have been copied to another location it's ok to delete all of them.
Under the new phase, the filelist.txt contains the file list and extra info. Thus filelist.txt cannot be deleted on the client side. Is it ok to delete the .log and .val files and to leave an erroneous filelist.txt file behind? It is erroneous because it lists files for upload which are no longer present in the current directory. If I don't delete the .log and .val files then the amount of traffic will keep on growing and growing.
Please respond as soon as you can since there are quite a few computers out there (hiya djp) running dfQ and I'd like to offer them as seamless a transition to Phase II that I can.
-
Moderator
Well I think it would be best to upload and then erase the val and log from the 'no net' machine, and then put the update filelist.txt back on the no net machine after the upload. Then the client would never know what you did. Also keep in mind it keeps the last .val file in filelist.txt around normally (on the no net machine) even after uploading so do NOT delete this one. (You can try it with the beta client if you wish, it should not change for the release).
If you need to discuss further, please e-mail to trades@mshri.on.ca
-
dfQ creator
Ok, guess that took care of one of my next questions.
Next problematic thing (just realized this):
uploads ONLY take place after a generation has completed, correct?
so if an upload is attempted before the end of a generation is there any sure-fire way to know whether the upload succeeded? (if nothing should be uploaded, then nothing happening would qualify as success, as far as I'm concerned)
The only thing I can think of is to check the error.log file to see if it has changed at all... hmm, guess the easiest thing to do would be to backup error.log, delete it, and then attempt the upload. If there were no errors then the error.log shouldn't exist. After the upload I can restore from the backup.
Should work, "in theory"
Thanks for being so prompt!
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules