The shell command touch -t 2203231037 file stores the year in the HH:MM file attribute resulting in 2022 instead of 10:37. This is a curriculum exercise, with the remark that this side effect won't be consider as wrong for the purpose of the exercise.
However, what is the correct usage of the touch command to get the right time posted for hours and minutes?
I used google but it seems it didin't returned me any relevant links.
Same goes for the reommendations here, so I think I have to ask this as a new question.
Can I run an exe command, but with a timeout included?
Example:
Run the exe, if it does not end alone within 5 minutes, kill it.
The 5 minutes limit is an example, I might want to set it up to 48 hours or something.
Is there a way to do it?
In my office they every day double click on the program vsubst to assign a partition of the space on the computer as a drive. I want to make a batch file out of it so they do not have to do this every day. It takes 5 seconds, but 5 people times 5 seconds times 250 working days is 6250 seconds a year!
Can anyone help me out here? This shouldnt be to difficult. I run a windows machine and could put it in the windows task manager.
I guess its something like: Start ....vsubst.exe param param1
Ok. Trial and error got me there. Fill the following line in and place the batch file in your startup programs and you're done :D
start path\VSubst.exe NEWDRIVE FOLDERPATH
exit
I am running a vb.exe through automation. In exe I have return a code which takes a data from database and saves that data into file. I ran that .exe for the first time. It took 1 mins. For testing baseline I called same .exe 5 times one after the other. But it took nearly 10 mins to generate.
My question is if it takes 1 min for 1 report to generate then it should take 5 mins to generate 5 report but why it is taking 10 mins (more than the double). Is there any problem while calling a exe one after the other?
No, there isn't a problem with calling an exe multiple times. However, there might be a problem with the data that you're fetching or writing. Maybe you didn't close the database connection correctly upon exiting the program and this causes a delay when you try to read from the database the second time.
But then again... without a more accurate description of what your program exactly does and the relevant pieces of source code, it's very hard to be more specific...
To clarify, I mean time spent while the system is suspended/hibernated, not the calling thread (GetTickCount() returns the number of milliseconds since system boot).
As far as I know, GetTickCount is unrelated to threads and counts the time since the system has started. But it is better to use GetTickCount64 to avoid the 49.7 day roleover.
By the way, to get what you want you need the GetThreadTimes function. It records the creation and exit time and the amount of time the thread has spend in user or kernel space. So you have a nice way to calculate the amount of time spend.
Ok, I missed the "system" part of the question. But that is simple. When in hibernation GetTickCount continues the counting. Because people have suffered from the 49.7 days bug when the computer was in hibernate most of the time. See link text here for more information.
Short answer : Yes.
Longer answer: Read the GetTickCount() docs: It's the elapsed time since system startup, and even MS wouldn't suggest that time stands still while your computer is hibernating...
Yes, GetTickCount does include suspend/hibernate time.
In the following python script I call the Sleep API to wait 40 seconds to give me a chance to put the computer into hibernate mode, and I print the time before and after, and the tick count difference after.
import win32api
import time
print time.strftime("%H:%M:%S", time.localtime())
before = win32api.GetTickCount()
print "sleep"
win32api.Sleep(40000)
print time.strftime("%H:%M:%S", time.localtime())
print str(win32api.GetTickCount()-before)
Output:
17:44:08
sleep
17:51:30
442297
If GetTickCount did not include the time during hibernate it would be much less than the time I hibernated for, but it matches the actual time elapsed (7 minutes 22 seconds equals 442 seconds, i.e. 442000 millisecond "ticks").
For any one looking for answer under Windows CE platform, from docs:
http://msdn.microsoft.com/en-us/library/ms885645.aspx
you can read:
For Release configurations, this function returns the number of
milliseconds since the device booted, excluding any time that the
system was suspended. GetTickCount starts at 0 on boot and then counts
up from there.
GetTickCount() gives you the time in milliseconds since the computer booted. it has nothing to do with the process calling it.
No, GetTickCount() does not include the time the system spend during hibernate.
A simple test proves this.
in Python:
import win32api
win32api.GetTickCount()
-- do hibernate --
win32api.GetTickCount()
and you'll see the result...