Jump to content

AGH1965

Members
  • Content Count

    82
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by AGH1965

  1. @Sammo Why do you think it is protected after renaming?
  2. As soon as possible may mean as soon as possible for ESET, but certainly not for EIS. So now ESET knows what to do: Make as soon as possible also mean as soon as possible for EIS by removing the unwanted thresholds (23 hours for daily tasks and 6 days and 23 hours for weekly tasks) from the scheduler. I'm looking forward to version 12.2...
  3. Indeed, I think that this is exactly what ESET intended with the scheduler. So weekly is considered much more important than the configured day and time. It would be nice if our ESET representative would confirm that. So the main thing that is wrong is naming the option "as soon as possible", because that is certainly not what it does.
  4. Support ticket? Why? What is the use of this forum if you don't use it as input for improving your products? Both itman and I gave enough information for any decent software tester to find out what is wrong. Besides, some of the behavior seems very deliberate. (For example the 23 hours or the 6 days and 23 hours.) Personally I think the scheduler does what was intented by the programmers. So probably it is no bug but a misunderstood feature. This forum could be very helpful explaining customers why the product behaves the way it does and what the intentions of the programmers were. Why don't you do that?
  5. Here some more results: If consecutive scheduled daily scans can't run at the scheduled time, then the scan will only be done as soon as possible if the previous scan was at least 23 hours ago. If that is not the case yet, then EIS will wait until it is. If consecutive scheduled weekly scans can't run at the scheduled time, then the scan will only be done as soon as possible if the previous scan was at least 6 days and 23 hours ago. If that is not the case yet, then EIS will wait until it is. In my opinion this is not how it should be! For example: A scan is scheduled to run every Monday at 00:00:00, but it doesn't get the chance to run at that time. The computer isn't booted any earlier than Wednesday 20:00:00, but almost directly after booting the missed scan is executed. The next week again there is no chance to run the scan at the scheduled time, but now the computer is booted on Monday at 08:00:00. I would expect the scan to run then almost directly after booting, because it is scheduled to run every Monday at 00:00:00 and in this case 08:00:00 is as soon as possible, but instead EIS decides to wait until Wednesday 19:00:00, which is 6 days and 23 hours after the previous scan. In other words, if there is never a chance to run the scan at the scheduled time, then it will take many weeks to get the scan running on Monday again, because the time will only be advanced 1 hour a week.
  6. Also in my case this solved the problem. Thanks! It is quite a coincidence though, that both TomFace's computer scan log and mine stopped working in the beginning of April.
  7. Aren't the rules checked from top to bottom until one is applicable?
  8. Isn't all outgoing traffic allowed in automatic mode? Can I simply add a rule or do I have to put it above the predefined rules? The order of the rules is important, isn't it? I do want the app; I just don't want it calling home.
  9. Many years I used the firewall's interactive mode, but now Windows 10 apps keep moving to new folders with every update, that became too much hassle to continue. Therefore I switched to automatic mode. However, I would like to block network traffic of a specific app. Is that possible in automatic mode?
  10. In my case every entry in the log corresponds with one file in C:\ProgramData\ESET\ESET Security\Logs\eScan. So scheduled scans that ran but did not appear in the log, don't have a file in C:\ProgramData\ESET\ESET Security\Logs\eScan.
  11. Same issue. Of course missed scans will never appear in the log file. Scans that run at the wrong time, shall appear though, but since the beginning of April that is no longer the case.
  12. For me the problem appeared a few days earlier. I reported it here.
  13. A few weeks ago I had a similar issue with 12.1.34.0 and I use interactive mode. Since the issue occurred only once, I didn't pay much attention to it, but this is what I remember: I was editing a firewall rule and at that moment another program without firewall rule tried to access the internet. The dialog popped up to ask if I wanted to create a rule and I tried to do that, but it could not be saved. After that all firewall rules I tried to edit, could not be saved either. After a reboot everything was back to normal.
  14. @Marcos Why do you want EIS to have an inconsistent user interface? A user without administrator rights can edit a scheduled scan if he knows the administrator password, but when such a scheduled scan is running, then that same user can't interrupt it. That is very inconsistent. It doesn't make sense. Nowadays most administrators use an unpriviledged account for normal work and make use of UAC to do things that require administrator rights. Please support that, ESET.
  15. Indeed! What is the use of adding features to a product when these don't work? Customers remember failures better than successes. Therefore, either get rid of features that don't work or fix them.
  16. Today the scheduler started 2 identical scans at the same time directly after booting, but only one of them is shown in Log files - Computer scan. I'm about to throw in the towel. The more thorough you look at EIS, the more strange things you notice.
  17. Unfortunately I can no longer monitor the erratic behavior of the scheduler. None of the scans executed after April 1st is visible in Log files - Computer scan. I'm not aware of changing any setting.
  18. Well, I tried it, but it didn't make me happy. I discovered quickly that ecls.exe is in folder C:\Program Files\ESET\ESET Security. So I used that same path for the /base-dir option, like in the example. The scanner reported an initialization error though. It toke me quite some time to figure out that not using the /base-dir option solved this problem. Then the other command line options puzzled me. The description of the /auto option says: "Scan and automatically clean all local disks." Yes, I want to scan all local disks, but I don't want to clean automatically. So, I didn't dare to use the /auto option. I found the option /clean-mode=None though. The description says: "No automatic cleaning will occur." So I chose that instead of the /auto option. However, will the scanner still scan all local disks? Furthermore I chose the /aind option. The description says: "Show activity indicator." However, the system tray icon didn't show the animation it normally shows during scanning. Neither did egui.exe show any scanning activity. I guess ecls.exe isn't the right tool for me. I would prefer a command line tool that triggers normal scans that are visible in egui.exe. Also I would like to make use of the predefined scan profiles available in egui.exe.
  19. Why? egui.exe has many buttons that are visible for all users, but that are only useful for those who know the administrator password. Why make an exception for stopping active scans? The behavior was certainly like that. I'm not saying the button disappeared with v12.1.31.0. That may have happened with an earlier update. I just noticed the absense with that version. In the past the button disappeared once more with an update. At that time it was reported at this forum and with a later update it reapppeared. (For some odd reason old posts seem to have disappeared from the forum.) However, there is a work-around. Normal users can stop an active scan. They can start egui.exe as administrator. However, if they close that egui.exe, then the normal one doesn't open anymore. That is a bug. Showing a useful button isn't though.
  20. I configured a daily scan at 17:55, but this time with the "immediately, if time since last run exceeds a specified value (hours)" option activated in combination with a 1 hour setting. Yesterday the scan started at 17:55 as scheduled. So it wasn't missed, because I forgot to switch off my computer on time. Oops, sorry. However, today the scan started at 16:56. So either one hour too early or 23 hours after the previous scan. Again I don't get the logic. Hopefully @Marcos is willing to explain.
  21. Description: Button to stop active scan also visible for users without administrator rights. Detail: In the past the button to stop an active scan was also visible for users without administrator rights. When such users pressed the button, they had to enter the administrator password. In my opinion that is how it should be. Unfortunately in v12.1.31.0 the button is not visible for users without administrator rights.
  22. Oh no, the situation became even stanger. I reported already that the weekly scan on Monday started 36 minutes too early at 17:24, which was exactly 6 days and 23 hours after the previous scan, but that is not all. At 18:00, i.e. at the scheduled time, the scheduler started a second scan. Two scans trying to beat each other. Why on earth? @itman and I can easily notice that the scheduler doesn't do what it is supposed to. Why can't ESET?
  23. @itman You reported that your scheduler started a scan one hour too early. Are you sure it started the scan one hour too early or could it also be that the scheduler started the scan 23 hours after the previous scan? On one computer I configured a weekly scan on Mondays at 18:00 with "as soon as possible" option activated. Last week the scan was missed because the computer was switched on a little too late, but at 18:24 the scheduler started the missed scan. This week the computer was switched on at about 17:15, but the scheduler didn't wait till 18:00 to start the weekly scan. Instead the scan was started at 17:24. That is exactly 6 days and 23 hours after the previous scan. This together with the experiences I reported earlier, give me the impression that the scheduler has a "23 hours bug".
  24. @itman Indeed it is a massive improvement. We went from an option that didn't do anything to an option that doesn't do what it is supposed to. However, when I see this behavior, then it seems to me that ESET intented to create something much smarter than straightforward "as soon as possible" functionality. So maybe this behavior is exactly what ESET intended, but it isn't what a user expects when he reads "as soon as possible". So maybe ESET should consider renaming the option.
  25. @Marcos Can you explain what algorithm the "as soon as possible" option uses for starting missed scans, because it is certainly not straightforward as soon as possible. To test the "as soon as possible" option of the scheduler, I configured a daily scan at 20:00 with "as soon as possible" option activated, but normally my computer is switched off before 20:00. So normally EIS misses the scheduled scan. When I turn on my computer the next day, then EIS doesn't start the scan as soon as possible as I would expect, but instead EIS waits till the end of the day. For example, yesterday EIS started the missed daily scan at 17:36:44 and today EIS started the missed daily scan at 16:36:53. Is it a coincidence that there is almost exactly 23 hours between the two scans or is that part of the "as soon as possible" algorithm EIS uses?
×
×
  • Create New...