I have a simulator application which writes some enrypted data into a text file. The information that it writes also has the timestamp (which the application picks from system time) along with it which I can not see. I have automated this whole task of sending random data from application to the text file but I want that the records must be written with some time interval in between.
For this I can either put delay in my automation script or I can change the system time every time a new record is inserted.
If I adopt the second approach i.e. I programatically change the system time very frequently (about once in every second) would it cause any harmful effect on the Windows system on which I am running this application ? Would any other critical system processes get affected by it ? Is this approach advisable ?
The best option here is just going to be putting in a delay in the automation script. I can't think of any problems that would arise from changing the system clock every second, but it's best just to let that be handled by the CMOS and any time syncing instead of setting it to change every second.
Changing the System Time might solve your problem, but at the same time it might have adverse affects on time dependent other applications sharing the same System. For example, the automatic antivirus signature updates are time dependent and might get impacted by explicitly changing the System Time or an automatic System Time adjustment for day light saving might get triggered at an inappropriate time. Keeping this issue in mind, the best bet would be to ensure that your application runs on an isolated environment i.e. ensure that other time dependent applications are not present in the same system and also to ensure that auto updates are kept off.
Changing the system time requires administrative privileges, so users of your application will be unable to run it as ordinary users.
Related
I have a script, which monitors some folder's subfolders, check their created date, and if DateDiff from created time and Now is more than 730(2 years) it deletes this folders. The problem is in that, if set current time on PC for 5/16/2015 - the script will delete folders, and it's not cool. I thought about getting time from some internet service, but there is no guarantee that PC will be connected to internet. So I tried to get BIOS time (I believe no users can change it to wrong), and compare folder's created time with this time. But, unfortunately I didn't find the way how to do that. Maybe you have any idea how to implement this task?
Having an incorrect date and time on a production-level machine is not an option nowadays. It will break a lot of things like HTTPS sites (they will fail to validate because of expired certificates), etc.
The system clock (BIOS time) is changed by the operating system whenever the time itself is changed in the OS, so you only have one clock in the computer. In other words the OS does not have a separate clock to track time with.
Nowadays most computers use the Network Time Protocol to keep their clocks in sync, so you should specify the correctly set time as a pre-requisite for your software. (Or you can just specify that the computer must be connected to an external atomic clock, but that's going to be expensive.)
How can I determine which processes are making changes to which files.
I did find this:
FileSystemWatcher: how to know which process made the change?
But I'm curious if anything has changed lately? Is it possible yet to determine which process is making changes to the file system, either using ReadDirectoryChangesW or anything else? I'd prefer not to have to write or use a kernel driver.
Create a security audit on the files you want to track. The information will be recorded in the security event log.
While it may be possible to find out the process that changes a file using kernel drivers (for example, process monitor), there will always be a problem identifying the process in case the folder is shared on the network, and a process on another computer modifies the file over the network.
Even the kernel drivers would in this case identify the network share process as the one accessing the file, not the process on the other computer.
I can't seem to comment yet. I would be interested in your Python code that creates a security audit on files or paths. It's a bit of a shame if it messes with the system security event log, but you can't have everything! :-)
Up until this point, I have been using GetForegroundWindow at the time of the change to eventually get the associated process. It only works well for changes initiated by the user, but that is primarily what I've been interested in. Besides background processes, the only minor issue is that sometimes a process is spawned just to accomplish a task (like a batch file) and it is non-existent by the time you want to learn more about it (like what process spawned it). I imagine that is a problem even with a security audit, though.
I saw this question in a forum about how an application can be developed that can keep track of the installation date and show trial period expired after 30 days of usage. The only constraint is not to use the external storage of any kind.
Question: How to achieve this?
Thanks
Bala
--Edit
I think its easy to figure out the place to insert a question work. Anyway, I will write the question clearly. "external storage" means don't use any kind of storage like file, registry, network or anything. You only have your program.
Use the file-modified date of the file containing the program as the installation date.
I like Doug Currie's idea of the file-modification date. But if the application is downloaded from the web, every night at midnight it gets relinked with new initialized data containing the new expiration date. Then any binary downloaded that day expires on the date given.
If you like, sign the date with a private key so it can't be hacked. Include a public key in the app and decrypt the date. If not correctly signed, hasta la vista, baby.
I don't know if this is possible, as most work I've done has been with embedded systems in which I don't even need to touch the operating system. But would the following be possible?
When compiling your program, leave some extra space at the end (say, 8 bytes), all set to 0. When your application is run, it fetches those bytes and if they're all 0, replaces them with the current time (That's the part I'm not sure about. Does the OS let you do that? If not, there might be some work-arounds using multiple processes.), otherwise, if the time difference is greater than 30 days, it notifies the user that the trial period has ended.
Of course, that method would be vulnerable to resetting the system clock.
If you can't use any external storage at all (not even config files or anything like that), you would need to code it into the app itself so the app's main method (or some method) checks if the current date is less than some expiration date. Part of your installer could actually compile that code on the fly and then it would be set to the installation date. This could be easily defeated by reinstalling the app, but then again, it's not realistic to have no external storage either.
I think the only way to do this generally would be to have your application spawn something off in a separate process that would continue to run and keep track of the date/time even if the main application were closed. When it was restarted, it would then connect to the running process to see if the trial period had expired.
Of course, this would only work if the computer was never restarted and the user never hunted down your spawned process and killed it, which is pretty unlikely. If your application does not do anthing IO-related (file system, registry, something on the network etc.), then a simple restart will wipe away anything that you've done.
So, to summarize: it's not really possible.
I'm using Google toolbox for Mac's GTMLogger to do logging to file in the app I'm working on.
I'm trying to decide how to do log file rollover when the file gets large enough.
Ideally I would like something like log4net's immediate rollover when the log file hits 1 mb with max 11 log files at any one time, but I don't see any built-in way to do this and I'm wondering if trying to add it is more trouble than it's worth.
The somewhat simpler option I can think of is just doing this check on app start-up and rolling over the log it it's over a certain size. The downside to this is of course if somebody leaves the app running for a week or two (and since a portion of the app is a launchd daemon this is a definite possibility for those who rarely restart), there could be a log file of non-trivial size built up during this period (depending on what logging level is enabled).
What's going to be my best option here?
You're worried that checking only at startup might not be often enough. So, throw a timer in your runloop at startup to trigger a log check immediately and once every day or two thereafter. If you're targeting using at most 1 MiB at a time, even if you do go over limit for a while, it likely won't matter all that much.
You could also just look at how log4net implements this feature: it's as simple as hooking each Append() to check that the size/date constraints are being met and adjusting the file logged to if necessary. See the RollingFileAppender source code for further details; start with AdjustFileBeforeAppend() and then check out RollOverSize(). It's Apache: Use the source!
The product we are working on allows the user to easily set it up to run automatically whenever the computer is started. This is helpful because the product is part of the basic work environment of most of our users.
This feature was implemented not so long ago and for a while all was well, but when we started testing this feature on Vista the product started behaving really weird on startup. Specifically, our product makes use of another product (lets call it X) that it launches whenever it needs its services. The actual problem is that whenever X is launched immediately after log-on, it crashes or reports critical errors related to disk access (this happens even when X is launched directly - not through our product).
This happens whenever we run our product by registering it in the "Run" key in the registry or place a shortcut to it in the "Startup" folder inside the "Start Menu", even when we put a delay of ~20 seconds before actually starting to run. When we changed the delay to 70 seconds, all is well.
We tried to reproduce the problem by launching our product manually immediately after logon (by double-clicking on a shortcut placed on the desktop) but to no avail.
Now how is it possible that applications that run normally a minute after logon report such hard errors when starting immediately after logon?
This is the effect of a new feature in Vista called "Boxing":
Windows has several mechanisms that allow the user/admin to set up applications to automatically run when windows starts. This feature is mostly used for one of these purposes:
1. Programs that are part of the basic work environment of the user, such that the first action the user would usually take when starting the computer is to start them.
2. All sorts of background "agents" - skype, messenger, winamp etc.
When too many (or too heavy) programs are registered to run on startup the end result is that the user can't actually do anything for the first few seconds/minutes after login, which can be really annoying. In comes Vista's "Boxing" feature:
Briefly, Vista forces all programs invoked through the Run key to operate at low priority for the first 60 seconds after login. This affects both I/O priority (which is set to Very Low) and CPU priority. Very Low priority I/O requests do not pass through the file cache, but go directly to disk. Thus, they are much slower than regular I/O.
The length of the boxing period is set by the registry value:
"HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\DelayedApps\Delay_Sec".
For a more detailed explanation see here and here
The program probably needs some more info put into its properties. It needs to "Run As", instead of just running.
Maybe this application should be developed as a service, instead of a program to be launched, or you could have service that launches the program when its determined the best window of opportunity.