Yikes - aside from some people not seeming to be able to understand the answers in this thread and re-asking the same question, this seems to be 'biting' a fair number of people and/or attracting a decent amount of attention...
Maybe this has been mentioned in other topics/conversations about this feature, and maybe I don't understand how this works by 'default' but since this seems to be getting in the way of some people using the project, would you guys consider trying a different approach in how it works? I'm not super fluent in the build process but perhaps you can change things around so that the INI file includes a generic 'number of days' value pair by default (say start = 30, end = 60) that (at build time) could be processed and then rewritten into hard adjusted expiry dates based on the current date of the system that the build is being done on? Of course I'd expect that you would still want to be able to manually run the config tool and hard set whatever values you want, which at that point would not be 'auto-adjusted' at build time... I'd also suggest getting rid of repopulating the internal default values every time the config tool is run since... as of the latest post before mine, some people still have not realized that rerunning the config tool resets the expiration dates from whatever they may have changed them to?
Default INI file - if detected by script during build process, the date values could be adjusted based on current time on build machine. If detected by config tool, the date values would read in the gui like "30 days from now" and "60 days from now"
Modified INI file - if detected by script during build process, the date fields would be left alone and there would be no expiration date. If detected by config tool, the date values would no longer be auto-filled with internal defaults...
And if the file were to be written by config tool or manually edited with hard adjusted dates (1/31/2007 & 2/28/2007) then things would work as above as well with no build-time adjustment, but the expiry being enforced as specified as well as not being overwritten by rerunning the config tool.
my two cents...
Edit- I'd also suggest that if an expiration is detected (but not yet expired) when booting into the UBCD4Win environment, that some additional pre-shell message is shown to indicate how many days left before use of the CD expires... Maybe that's already there and I just haven't seen it...
This post has been edited by steje: 07 February 2007 - 12:55 PM