Hi,

On 07/04/2021 14:05, Patrik Dufresne wrote:
Hello Eric,

Thanks for asking !

To give you a recent example. A new customer of mine has an error with it's backup and the following lines get added to error_log.

ListError Data/Projets2019/Photos_Maison_Halle/Photos_Maison_Halle/Espaces_au-dessus_des_portes/Poutrelle_01.jpg [Errno 13] Permission denied: 'D:/Data/Projets2019/Photos_Maison_Halle/Photos_Maison_Halle/Espaces_au-dessus_des_portes/Poutrelle_01.jpg'

In rdiffweb, these errors get displayed when the file contains something.
image.png
This could certainly be improved to get more error printed into this file as I've discover many are not getting written in that file.

Exactly my point, the `backup.log` contains more (all) information, I would like to have:

- only one file with all messages
- easier to parse than today:
* one unique line for each message
* information like type (ERROR, WARNING, DEBUG, etc) and date/time available

I don't think I care too much if it's a dated (like error_log.<date>) or an undated file (like backup.log), but I guess it's slightly easier to handle if it's dated?

What do you think?

KR, Eric

PS: no need to put me in copy, I'm on the mailing list...





On Sun, Apr 4, 2021 at 1:37 AM EricZolf <ewl+rdiffbac...@lavar.de <mailto:ewl%2brdiffbac...@lavar.de>> wrote:

    Hi,

    On 03/04/2021 14:42, Patrik Dufresne wrote:
     > Hello Éric,
     >
     > Ok using this file to verify if the backup run without error. In
     > rdiffweb and minarca, this is used to report the status of the
     > repository. When ever the file contains something, this mean
    something
     > wrong happen. E.g. lately, a customer backup is complaining about
     > permissions denied on windows.
     >
     > This is a neat way to spot those kind of problem and get them fixed.

    I'm wondering because from my analysis of the code, not all errors land
    in the error_log file, where they all land in backup.log resp.
    restore.log, so I don't think the approach is reliable.

     > So, I would say don't get rid of it.

    That's why I ask :-)

    KR, Eric



--
IKUS Software inc.
https://www.ikus-soft.com <https://www.ikus-soft.com>/
514-971-6442
130 rue Doris
St-Colomban, QC J5K 1T9

Reply via email to