Feature Request: Producing Error Reports & Saving Them.
Moderators: white, Hacker, petermad, Stefan2
- pdavit
- Power Member
- Posts: 1529
- Joined: 2003-02-05, 21:41 UTC
- Location: Kavala -> Greece -> Europe -> Earth -> Solar System -> Milky Way -> Space
- Contact:
Feature Request: Producing Error Reports & Saving Them.
I frequently copy large volumes of data. The other day, for example, I had to copy the entire user area (a whopping 23Gb) to a removable hard drive to cover user needs on an off-server-site location. The task was a colossal one as you can imagine since all shorts of problems like weird file names and files in use by applications, users, and network resources were causing problems in the coping process.
The whole process lasted from 8pm till 1am next day with my presence necessary in order to interact with the error messages. It wasn’t vital to have every single file copied as the completion of the task was more important (due to the tight deadline), than achieving an identical duplicate backup of the user area. So, skipping and/or ignoring copied data was the technique to follow in order to complete the task.
Of course in the long run, I wanted to have this copy updated to an identical duplicate due to the importance of some data. What someone can easily do in this case is to use TC to compare and synchronize the two locations but even then problematic files cause similar problems. Not to mention also that performing this synchronization a couple of weeks later can be confusing since the two locations were being used and updated simultaneously and separately (on-site and off-site users.)
It would be nice if TC could produce a report after coping is complete if and only if errors occur in order to help us the network administrators in similar situations. Being able to see this report as well as save it in text form, for example, can be very useful. Of course the report could include the typical information like source and destination locations, dates, the problematic files and the type of errors on the whole process. In reality this report could just be a capture of all the error messages TC produces.
I could have asked to be able to save the list shown on the synchronization window but this will not include only the ‘problematic” files but newly created ones also. Not to mention that some problems were the outcome of files being in use by system resources at the time of the coping process so there was no real problem with the integrity of those files.
I would appreciate any suggestions here concerning this feature or even a procedure to tackle this (you could say logical) problem YOU follow in similar situations. Thanx!
Kind regards,
Panos
PS: As an extension of the above… why not include an “Ignore All Types of Errors” button so that someone can perform the whole copying process without the need of user interaction with TC. I guess this should definitely be followed by a report just to be on the safe side!
Last edited by pdavit on 2003-06-13, 15:06 UTC, edited 1 time in total.
"My only reason for still using M$ Window$ as an OS is the existence of Total Commander!"
Christian Ghisler Rules!!!
Christian Ghisler Rules!!!
I agree with you, it can be useful. Current Copy dialog has button Options that opens popup menu. Future TC versions can have some additional options (e.g. "Save error report"), so it would be more convenient IMHO, if this dialog had ">>" button (or any other title) that will expand it (dialog) to show these additional options ("Ask user", "Overwrite all", "Save error report", etc). Button changes to "<<" allowing to shrink the dialog to normal size. The state of the dialog (normal or expanded) is remembered for the next times.
Current "Options" button IMHO looks... (don't know how to say in English) ...a bit strange.
Current "Options" button IMHO looks... (don't know how to say in English) ...a bit strange.
Yes this would be a very useful addition to the copy/move functionality.
I think it could be useful, too, if there were the possibility to save the whole actions on the copy process - not only the faulty ones but also the successful. This could be enabled via a ini setting like it is done already for ftp with
sheepdog
I think it could be useful, too, if there were the possibility to save the whole actions on the copy process - not only the faulty ones but also the successful. This could be enabled via a ini setting like it is done already for ftp with
Code: Select all
Logfile=
Logfile2=
"A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete fools."
Douglas Adams
completely foolproof is to underestimate the ingenuity of complete fools."
Douglas Adams
I've seen that ignore all errors is a common request, and it's still ignored... One could synchronize, and after that reCheck (re-Synchronize) to see what was missed. But for this it's essential an ignore all errors for copying. Usually I deal with fawlty HDs and the first thing is to copy as many files as it's possible, and wish to have a Key-Press device (as in a simpson's episode) to continually press Skip.... I really think it's not so difficult to implement.
- majkinetor !
- Power Member
- Posts: 1580
- Joined: 2006-01-18, 07:56 UTC
- Contact:
Log file support ++
A good idea is an ini parameter with a log destination path.
If the parameter value is empty the TC create no log files.
At this location every day the TC create a new file. For example "yyyymmdd.log".
In ini file also a parameter like DeleteOlderLogFiles=30.
With this parameter the TC delete all older files log in log folder.
The log file content should also contain an type information.
For example:
INFO = successful operation,
WARNING = inform the user about canceled operations (could not copy the "file" etc.) and
ERROR = tc errors (...send the log file to the author).
A good idea is an ini parameter with a log destination path.
If the parameter value is empty the TC create no log files.
At this location every day the TC create a new file. For example "yyyymmdd.log".
In ini file also a parameter like DeleteOlderLogFiles=30.
With this parameter the TC delete all older files log in log folder.
The log file content should also contain an type information.
For example:
INFO = successful operation,
WARNING = inform the user about canceled operations (could not copy the "file" etc.) and
ERROR = tc errors (...send the log file to the author).
Räubi
(#2852 + #287609)
(#2852 + #287609)
-
- Junior Member
- Posts: 22
- Joined: 2005-03-14, 18:13 UTC
- Location: Uvalde, Texas
error log
An error log would be of great value to me too. I also am a network admin, and move a lot of files. If I could have TC ignore errors, log them, and then I could come back and fix the problems, would save me a lot of time.
In reality, I would have the feature shut off most of the time, but it could be a time saver from time to time.
In reality, I would have the feature shut off most of the time, but it could be a time saver from time to time.
- ghisler(Author)
- Site Admin
- Posts: 48118
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
TC7 will have a log file. I'm currently discussing with beta testers what should be logged and what not.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
-
- Junior Member
- Posts: 22
- Joined: 2005-03-14, 18:13 UTC
- Location: Uvalde, Texas
logging errors
Fantastic.
If possible, could we have a way to tell TC to log to a specific level, but not everything? Preferably with a setting in the ini file.
For example, log that the drive is full when copying file #35 of 500, but not the failure to copy the rest of the 465 files. Maybe at this point have an option to stop the copy job completely, or continue with the next queued copy operation.
If possible, could we have a way to tell TC to log to a specific level, but not everything? Preferably with a setting in the ini file.
For example, log that the drive is full when copying file #35 of 500, but not the failure to copy the rest of the 465 files. Maybe at this point have an option to stop the copy job completely, or continue with the next queued copy operation.