|
|
Comments and Discussions
|
|
 |

|
While checking something else, I just discovered a situation indicating that the report of my experiments in my last post was wrong in two important parts. My statements about the lack of changes to the modified date of the INI file were based on what I saw in Everything, which is supposed to (and always had, so far as I’m aware) report any file activity in the NTFS by querying the USN Change Journal. However, when I looked at the information about the INI file itself, in Explorer, I found that the modified date was showing as changed, although Everything did not report that change. Secondly, my statements about the lack of changes to the content of the file itself were incorrect. I was looking at the INI file as a text file using EditPad. It does not lock files when it has them open, but is designed to display a notice that the file has changed on disk when that happens. I thought that notification was persistent, but apparently it disappears after a brief time, so that when I came back to look at the file after each stage of the experiment, I had no indication that anything had changed. Repeating the experiments, and looking directly at the INI file itself, I find that it does update on disk when reminders are added, but that this happens only when TDL itself exits. Is that correct? With that established, I then reopened TDL, and “cleared” one of the reminders I had just set. After exiting TDL, the INI file still showed the section for that reminder, but now it was showing as disabled, instead of the entire section having been removed. That seems like a design flaw. While a choice for the user to disable a reminder might be useful, it seems like not “clearing” the reminder information when it is cleared by the user just leads to the accumulation of needless, obsolete data in the INI file. What do you think? At this point, it seems like we can say that the program is saving the INI file properly when it exits, but not any other time. I think that behavior needs to be changed. On my system, TDL list is loaded with Windows, and almost never closed by me. 99% of the time, the TDL process is still open when I restart or close Windows, and is shut down by Windows along with all the other processes. That means that 16 – 20 hours might pass every day without any of the changes that should be stored in TDL.ini having been saved. That leaves important TDL data vulnerable to any TDL “crash” or “hang.” which would occur without any of the results of certain types of work performed since the program was opened having been saved to disk. However, In this particular situation, the Problem Reports and Solutions history doesn’t show any entry for any problems with TDL during the relevant period. Moreover, Windows System Event Log show only one system restart during the relevant period, and no “error” type messages indicating a Windows problem. For that same period, the Application Log show no events related to TDL, and nothing suggesting any type of system crash. Unfortunately, I don’t think that news gets us any closer to an answer about why TDL didn’t save the INI file properly during the period in question, at least during the restart at 11:04 AM on 3/10. I don’t believe I worked with TDL any further until I discovered the reminders missing about 11 hours later, and began the investigation that led to my initial post. Any ideas?
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
|
A hierarchical task manager with native XML support for custom reporting.
| Type | Article |
| Licence | Eclipse |
| First Posted | 3 Nov 2003 |
| Views | 12,718,618 |
| Downloads | 224,935 |
| Bookmarked | 2,918 times |
|
|