No torrent for 1.05 this time? Apparently not very useful because of small file size?
On one machine (Win 7, Avast AV free/Home), installation went fine.
On other machine 6 hours later (Win 7, Avast AV Pro) the AV complained about it being suspicious, that the BT_1.05.exe tries to start BT_1.05.tmp and whether I really want to allow it... Twice, for both BT_1.05.tmp files. But no complaints regarding any ill contents of the file.
Upon the first start on the second computer, BT 1.05 said I've 19 Notices, after switching to the tab it was empty and keeps empty. I suspect some inconsistency between my own notices templates and the update from BT 1.05, will investigate and report. On the first mentioned machine (without customized notices' templates), the Notices were displayed correctly, including their "+" and "x" marks.
Quote from: Pepo on June 07, 2011, 01:20:53 PM
No torrent for 1.05 this time? Apparently not very useful because of small file size?
There are very few users and with 2 servers the availability is very high.
The old Notices template needs to be adjusted for the use of the collapse and delete feature.
Strange that the virus scanner is complaining, both the installer and all the exe's are secure and signed. And above all the installer is the same as before.
Quote from: fred on June 07, 2011, 01:27:51 PM
Strange that the virus scanner is complaining, both the installer and all the exe's are secure and signed. And above all the installer is the same as before.
As I said, it did not complain about the file contents, but possibly the behavior (maybe executing a .tmp file? does the signature also contain the file name?).
Now I remember, the exact question was, whether I'd rather like to execute it in a sandbod, normally or not at all. This is probably the reason, why the first computer's AV did not complain - the free version does not contain a sandbox functionality. (I remember having seen this sandbox question once or twice in the last 10 days or so, but not any more the application name - possibly some BOINC task?)
Quote from: Pepo on June 07, 2011, 02:34:24 PM
As I said, it did not complain about the file contents, but possibly the behavior (maybe executing a .tmp file? does the signature also contain the file name?).
It's the installer and I don't know exactly what's it ..... but it probably makes some temp to expand the setup file.
All exe are signed as is the setup.exe, that should normally be enough to call it trusted. It should prevent any form of tampering.
Quote from: fred on June 07, 2011, 02:38:32 PM
Quote from: Pepo on June 07, 2011, 02:34:24 PM
As I said, it did not complain about the file contents, but possibly the behavior (maybe executing a .tmp file? does the signature also contain the file name?).
It's the installer and I don't know exactly what's it ..... but it probably makes some temp to expand the setup file.
All exe are signed as is the setup.exe, that should normally be enough to call it trusted. It should prevent any form of tampering.
I do not know... ???
The sequence I always see in the Process Explorer: the first instance of any
BT n.nn installer (now 1.05) (running under my account, file "
%HOMEPATH%\Downloads\BOINC\setup_32_64_boinc_tasks_1_0_5.exe") creates a child process by launching file e.g. "
%LOCALAPPDATA%\Temp\is-IQIL5.tmp\setup_32_64_boinc_tasks_1_0_5.tmp" under my account (this is the point where the AV complains for the first time "You are opening an app, which might be dangerous. We recommend opening it in a sandbox...") - I believe this one is launching an UAC request.
Afterwards the "
%HOMEPATH%\Downloads\BOINC\setup_32_64_boinc_tasks_1_0_5.exe" will be executed again, under an admin's account, which in turn creates a child process by launching file e.g. "
%LOCALAPPDATA%\Temp\is-EDG0V.tmp\setup_32_64_boinc_tasks_1_0_5.tmp" (in the admin's
%LOCALAPPDATA% folder tree) again under the admin's account (this is the point where the AV complains for the second time) - I believe this is the final installer. Both processes' current dir is "
C:\Windows\SysWOW64\"
I've compared these two .tmp files - they are binary identical (uploaded to SK). After renaming it to .exe and launching it, the AV complains again the identical way. The file does not contain any signature, just the parent installer envelope. It just complains:
---------------------------
Error: The file setup_32_64_boinc_tasks_1_0_5.tmp-0.bin is missing from the installation directory. Please correct the problem or obtain a new copy of the program.
---------------------------
I could not find the .bin data file, but this is not important anymore.
No solution idea on my side. I know that the installation always proceeded like this, possibly just the AV team added some new heuristics...
Quote from: Pepo on June 07, 2011, 03:31:09 PM
No solution idea on my side. I know that the installation always proceeded like this, possibly just the AV team added some new heuristics...
I updated the installer, maybe that does something for the next release.
Again the nasty hidden bug with incorrect times, while an active task does not run. This time I've noticed it immediately because of the
-23.198% progress (nothing wrong with correctly displaying an eventually incorrect value) and and the progress bar going
to the left of the Progress% column (not so correct). (Screenshots at hand. I've suspended this task.)
Quote from: BT Tasks tabApp=6.52 QCN Sensor (nci) Name=qcnac_097909_0 Elapsed(CPU)=05:07:18 (00:00:28) Progress%=-23.198 Remaining= "-" Deadline=01d,22:43:43
Quote from: BT Task's PropertiesWU name qcnac_097909
Received 26.05.11 23:32
CPU time at last checkpoint 00:00:28
CPU time 00:00:28
Elapsed time 05:07:18
Remaining time estimate -01d,03:11:58
Finished part 0.000 %
Quote from: Fragments from client_state.xml
<active_task>
<project_master_url>http://qcn.stanford.edu/sensor/</project_master_url>
<result_name>qcnac_097909_0</result_name>
<active_task_state>0</active_task_state>
<checkpoint_cpu_time>28.626190</checkpoint_cpu_time>
<checkpoint_elapsed_time>212006.004143</checkpoint_elapsed_time>
<checkpoint_fraction_done>0.000000</checkpoint_fraction_done>
<checkpoint_fraction_done_elapsed_time>0.000000</checkpoint_fraction_done_elapsed_time>
<current_cpu_time>28.626190</current_cpu_time>
</active_task>
Quote from: BM Tasks tabApp=6.52 QCN Sensor (nci) Name=qcnac_097909_0 Elapsed(CPU)=58:53:26 Progress=0.000% Remaining= "---" Deadline=9.6.2011 23:32:15
Quote from: BM Task's PropertiesWU name qcnac_097909
Received 26.05.11 23:32:17
CPU time at last checkpoint 00:00:28
CPU time 00:00:28
Elapsed time 58:53:26
Remaining time estimate ---
Finished part 0.000 %
Could I somehow help with localizing the reason for the wrong times' bug?
Quote from: Pepo on June 08, 2011, 12:48:18 AM
Again the nasty hidden bug with incorrect times, while an active task does not run. This time I've noticed it immediately because of the -23.198% progress (nothing wrong with correctly displaying an eventually incorrect value) and and the progress bar going to the left of the Progress% column (not so correct). (Screenshots at hand. I've suspended this task.)
Could I somehow help with localizing the reason for the wrong times' bug?
I will do a check and a partial rewrite for 1.06, if nothing helps, I will add some debugging options.
Quote from: Pepo on June 08, 2011, 12:48:18 AM
Could I somehow help with localizing the reason for the wrong times' bug?
When running:
dElapsed = pResult->elapsed_time;
dCurrentCpuTime = pResult->current_cpu_time;
When not running:
if (pResult->final_elapsed_time > 0)
{
dElapsed = pResult->final_elapsed_time; <-- this is probably where it goes wrong.
}
else
{
dElapsed = pResult->elapsed_time;
}
I will add this:
if (pResult->active_task)
{
dElapsed = pResult->elapsed_time; <-- takes the elapsed_time
dCurrentCpuTime = pResult->current_cpu_time;
}
else
do the above
I corrected the elapsed time for the tasks tab as well.
Quote from: Pepo on June 07, 2011, 02:34:24 PM
(I remember having seen this sandbox question once or twice in the last 10 days or so, but not any more the application name - possibly some BOINC task?)
Today I've got this sandbox question for
dnetc_2.02_windows_intelx86.exe. Then I've allowed its normal execution and checked the executable - it was confirmed virus-free.
The
avast AV is either getting over-careful, or implements some new security mode "complaining-prior-to-testing"?
::)
I'm using my own modified notices_template.html, which also makes use of __InsertNoticeTimeArrival__. Now it seems like both __InsertNoticeTimeArrival__ and __InsertNoticeTimeCreated__ are not being expanded (i.e. they are converted to empty string), when a notice is in a collapsed state. I wanted to display their times also in this state.
Could they please be expanded regardless of their state?
Quote from: Pepo on June 08, 2011, 04:46:00 PM
I'm using my own modified notices_template.html, which also makes use of __InsertNoticeTimeArrival__. Now it seems like both __InsertNoticeTimeArrival__ and __InsertNoticeTimeCreated__ are not being expanded (i.e. they are converted to empty string), when a notice is in a collapsed state. I wanted to display their times also in this state.
Could they please be expanded regardless of their state?
I should expand the time as it's shown in the default template.
Check the created html file to see what has happened to the time.
can you email the file, I will take a look at it.
Quote from: fred on June 08, 2011, 04:52:34 PM
Quote from: Pepo on June 08, 2011, 04:46:00 PM
[...] it seems like both __InsertNoticeTimeArrival__ and __InsertNoticeTimeCreated__ are not being expanded (i.e. they are converted to empty string), when a notice is in a collapsed state. I wanted to display their times also in this state. Could they please be expanded regardless of their state?
I should expand the time as it's shown in the default template.
Check the created html file to see what has happened to the time.
can you email the file, I will take a look at it.
The places where the times should appear are simply empty. I'll send you the template and resulting file.
Possibly the same with the "more..." link element
__InsertNoticeMoreLink__ - could it be expanded in a collapsed state, if placed outside of the notice body?
BTW, the red "delete notice" icon is prefixed with blue underscore (which both belong to the same delete link): "
_[x]". Is the tiny underscore necessary there?
Quote from: Pepo on June 08, 2011, 05:06:15 PM
The places where the times should appear are simply empty. I'll send you the template and resulting file.
Possibly the same with the "more..." link element __InsertNoticeMoreLink__ - could it be expanded in a collapsed state, if placed outside of the notice body?
BTW, the red "delete notice" icon is prefixed with blue underscore (which both belong to the same delete link): "_[x]". Is the tiny underscore necessary there?
I have no idea where the partial square comes from, it's not in the picture as far as I can see. It looks like the rectangle that is set to 0.
In 1.06 I create 2 separate bodies, one normal and the other collapsed. This will make customizing a lot easier.
And I borrowed some of your ideas.... :o
Quote from: Pepo on June 08, 2011, 05:06:15 PM
BTW, the red "delete notice" icon is prefixed with blue underscore (which both belong to the same delete link): "_[x]". Is the tiny underscore necessary there?
This: <FONT COLOR="#ffffff"__InsertNoticeDelete__</FONT> hides it, but I still don't know why.
Quote from: fred on June 09, 2011, 07:11:01 AM
And I borrowed some of your ideas.... :o
Glad to hear it :)
Notices are not correctly being sorted (time-wise) - IIRC blocks of incoming notices should be sorted according to their "TimeArrival", notices in each block according to their "TimeCreated". Yet I see notice blocks from mixed dates/times in this order: 6.6. 11:49, 2.6. 15:05, 30.5. 15:05, 8.6. 20:55, 21.5. 07:56, 19.5. 16:40, 19.5.11 12:38, 8.6. 20:55, 15.5. 16:39, 12.5. 11:34, 8.6. 11:51, 8.6. 07:07, 6.6. 18:17, 6.6. 11:49, 8.6. 20:55. In the older versions I've never noticed the blocks being incorrectly sorted.
Among the blocks of grouped notices, notices are correctly sorted according to their creation times.
Quote from: BT New VersionAdd: BoincTasks new version in Notices.
I've got a BT 1.05 notification (
(http://www.efmer.eu/forum_tt/Themes/default/images/post/thumbup.gif) 8)):
Quote[-] 09.06.11 20:12
Oznam od BoincTasks
T�to verzia: 1.05
N�jden� nov� beta verzia BoincTasks: 1.06. Stiahnu� z n��ho servera, umiestnen�ho v: Eur�pe (http://www.efmer.eu/download/boinc/boinc_tasks/unified/setup_32_64_boinc_tasks_1_0_6.exe), Severnej Amerike (http://www.efmer.com/download/boinc/boinc_tasks/unified/setup_32_64_boinc_tasks_1_0_6.exe)
(??) viac... (http://www.efmer.eu/boinc/boinc_tasks/download.html)
but its "TimeArrival" is "??" and "TimeCreated" is continuously being updated with the wall-clock time ;D - I'd expect them to display the time-stamp, when my BT noticed it for the first time and another time stamp, when
eFMer, Inc. anounced it? ;)
But the most important problem is probably an incorrect code page for just this notice's text.
Quote from: Pepo on June 09, 2011, 06:38:03 PM
Notices are not correctly being sorted (time-wise) - IIRC blocks of incoming notices should be sorted according to their "TimeArrival", notices in each block according to their "TimeCreated". Yet I see notice blocks from mixed dates/times in this order: 6.6. 11:49, 2.6. 15:05, 30.5. 15:05, 8.6. 20:55, 21.5. 07:56, 19.5. 16:40, 19.5.11 12:38, 8.6. 20:55, 15.5. 16:39, 12.5. 11:34, 8.6. 11:51, 8.6. 07:07, 6.6. 18:17, 6.6. 11:49, 8.6. 20:55. In the older versions I've never noticed the blocks being incorrectly sorted.
Among the blocks of grouped notices, notices are correctly sorted according to their creation times.
Is the sorting correct in the BOINC Manager?
I didn't change any sorting, the list is straight from the Client.
Quote from: fred on June 10, 2011, 05:02:06 AM
Quote from: Pepo on June 09, 2011, 06:38:03 PM
Notices are not correctly being sorted (time-wise) - IIRC blocks of incoming notices should be sorted according to their "TimeArrival"...
Is the sorting correct in the BOINC Manager?
I didn't change any sorting, the list is straight from the Client.
I'm now behind a machine, which BT 1.05 displays Notices with the default template (no arrival time displayed). It displays 8 notices received from the client, with their creation times, sorted 28.5. 27.5. 25.5. 16.5. 26.5. (all 5 from SETI), 8.6. (BOINC test project), 10.6. 8.6. (from the client - can not recognize host address in remote_hosts.cfg).
B.Manager 6.12.28 displays these messages (mostly) in correct order, but one "can not recognize host address in remote_hosts.cfg" from 8.6. is placed at the end... But the orders definitely do differ.
On a third machine (with BT 1.04), 8 other notices are sorted equally in both BT and B.Manager 6.12.28.
BTW, when BT is connected to 2 machines, wasn't it supposed to display notices from both of them?
Quote from: Pepo on June 10, 2011, 05:46:15 AM
BTW, when BT is connected to 2 machines, wasn't it supposed to display notices from both of them?
Everything will be corrected in 1.07.
Quote from: Pepo on June 09, 2011, 06:38:03 PM
I've got a BT 1.05 notification ((http://www.efmer.eu/forum_tt/Themes/default/images/post/thumbup.gif) 8)):
Quote[-] 09.06.11 20:12
Oznam od BoincTasks
T�to verzia: 1.05
N�jden� nov� beta verzia BoincTasks: 1.06. Stiahnu� z n��ho servera, umiestnen�ho v: Eur�pe (http://www.efmer.eu/download/boinc/boinc_tasks/unified/setup_32_64_boinc_tasks_1_0_6.exe), Severnej Amerike (http://www.efmer.com/download/boinc/boinc_tasks/unified/setup_32_64_boinc_tasks_1_0_6.exe)
(??) viac... (http://www.efmer.eu/boinc/boinc_tasks/download.html)
but its [...] "TimeCreated" is continuously being updated with the wall-clock time ;D [...]
As I've not yet updated to 1.06, my
Notices still remind me on a new BT version (now from 14.6.2011 11:33, but this already is known
:)). But I was surprised that the "new version" was still 1.06 even after successfully checking for a new version in the "New version check" dialog, which confirmed, that the newest beta is 1.07. I think that the notice should have been replaced too.
Quote from: Pepo on June 14, 2011, 09:33:14 AM
As I've not yet updated to 1.06, my Notices still remind me on a new BT version (now from 14.6.2011 11:33, but this already is known :)). But I was surprised that the "new version" was still 1.06 even after successfully checking for a new version in the "New version check" dialog, which confirmed, that the newest beta is 1.07. I think that the notice should have been replaced too.
At least you know there is a new version.
Quote from: Pepo on June 14, 2011, 09:33:14 AM
should have been replaced too.
The version check is done every 12 hours.
Quote from: fred on June 14, 2011, 01:12:01 PM
Quote from: Pepo on June 14, 2011, 09:33:14 AM
should have been replaced too.
The version check is done every 12 hours.
The automatic one, sure.
But should (or could) a manual one trigger the notice too?
Quote from: Pepo on June 14, 2011, 06:47:55 PM
The automatic one, sure.
But should (or could) a manual one trigger the notice too?
But a notice is something you should see and you already did saw that one. 8)
Quote from: fred on June 14, 2011, 07:03:11 PM
Quote from: Pepo on June 14, 2011, 06:47:55 PM
The automatic one, sure.
But should (or could) a manual one trigger the notice too?
But a notice is something you should see and you already did saw that one. 8)
Well, if I would like to be consequent, then a) I've not yet seen a notice for 1.07, just 1.06, and b) if seeing it in the check dialog would be a reason to not display a 1.07 notice anymore, then why is a 1.06 notice still visible? ;)
IMO: If any version notice is in the
Notices area and a newer version gets available, the notice should be replaced, even with the 12 hours delay (imagine, a "new TTh version" notice from all connected machines, until all are get up-to-date), and such notice(s) should be kept until a) the application gets updated, or b) the single notice(s) is/are manually deleted.