On 11/14/22 12:57, [email protected] wrote:
> Can you define how this situation is a "phantom bug". I pretty
> clearly explained the lack of feedback from the UI when this condition
> occurs and you get sent a zero byte zip file with no explanation.
The logs were clear -- this is Enterprise software and when something
doesn't work, one is expected to check the logs (as well as doing
other basic troubleshooting homework). If backups or restores don't
work -- for whatever reason -- the first thing to do is check the
logs!!! (how many times do I have to say that???)
Correct, the logs were clear. Honestly I didn't expect to see anything
in the logs. You don't have to say it anymore as someone else already
commented. When you're sounding like a broken record, the first thing
to do is switch to a new record. If you feel like you're owed an
apology, then sure. I made a bad assumption here about where the
details about the backup download would appear.
This is not child-proof Windows consumer software where the UI is
expected to do everything and spoon-feed all the answers. The GUI is only
there to help with basic tasks -- indeed the GUI itself is mostly
focused on making it easier for users to change config parameters and
launch backups/restores -- it is not meant to be idiot-proof or a
substitute for logs.
Speaking of assumptions. I never said it was child-proof windows
consumer software, but now that you explain the ideology behind what gui
is expected to do, this makes more sense now. Isn't this better? Now
we're getting some formal discourse and you're not just wasting energy
attacking someone you don't know on a list that in theory, is designed
to facilitate discussion about backuppc.
Indeed, many users (myself included) never even use the GUI since the
CLI is much more powerful and accessible. As such, there is not a huge
ongoing investment being made in adding more bells and whistles
(unless an individual user -- hint you -- contributes code).
Thanks for explaining the normal expected use.
The fact that the UI doesn't pop up a nice shiny, themed dialog box
explaining why your restore failed is NOT a BUG. At most, it's a feature
request to include more debugging info directly in the GUI -- and you
are welcome to submit code that provides such messaging.
Sounds like we have a different definition of bug. But sure, as a perl
developer I would be interested in addressing this.
That being said, the GUI did undoubtedly signal an error -- just not
in a pop-up. Had you looked under "Restore Summary", you would have
seen presumably that your restore had no files or no data. The top
status text may also have noted something.
The gui did not actually signal an error. Try a reproduction of this on
your own system. Do a zip file download from a system that has a
current backup job running. You'll notice that you get a zero byte zip
file. "Restore Summary" does not log this. There are no new entries in
the restore summary page to show there was any kind of restore issue.
The only place this is logged is under 'Log file' when doing a "Direct
Restore". The web page generated makes no mention of any issues
preparing the zip file.
Here's what happens.
Main 'LOG file
'2022-11-14 12:22:48 User backuppc downloaded zip archive for comm-nyc1,
backup 52; share /mnt/volume_nyc1_01; files were:
/debian-c-2-nyc1-01/var/log/apache2/access.log.169.gz
2022-11-03 08:08:49 Can't run BackupPC_zipCreate while BackupPC_dump
is running on host xyz
I don't get any new detail in 'LOG file' at the per-server level.
So it looks like it creates the zip file first, and then logs the
error... which to me is quite strange. Other than the global log,
there's no indication to the user that there's an issue. But.. now that
I know a zip file of size zero is indicative of an error occurring, I'll
be aware that this is the case going forward.
I can assure you that there are many, many even more egregious or
alternatively subtle ways for backups (or restores) to fail in part or
in full and there is no nice shiny GUI that signals many such
errors. That's why you need to check and test backups as well as
restores -- if there are issues, then... drumbeat... check the logs!
> Again... unneeded hostility.
Not hostility -- just reaction to:
1. Laziness -- you made all types of claims and request for help
before doing even minimal troubleshooting yourself
I already explained the reason behind the original posting. Obviously
you missed the part where I wasn't being lazy. It was more of a "omg
it's broken -- panic-mode" which is not my typical modus.
2. Calling "BUG" multiple times just because you didn't get the
notification in the way you wanted. At most this is a "Feature
Request" for more direct error messages for those who don't want to
trouble themselves to look in the logs or even on the status page.
Personally, though, I think adding more error messages will only
give a false sense of security leading users to think that their
backups and restores are intact just so long as they don't have
error messages. Given the large number of ways in which backups and
restores can fail subtly, this would only give a false sense of
security.
As a software developer myself.. my theory is that the more error
messages you generate for the user about what's going wrong, the more
likely the system will operate as intended.
Failing essentially silently gives the user more of a false sense of
security than anything else. Here's how I approach things.. by asking
myself questions like: Would you think that out of the box, a properly
configured and running backup system would send the user a zero byte
file under normal everyday circumstances without any immediate and
highly visible notification as to why it occurred?
I think most people... the answer would be a resounding 'no'. But I
think we can leave it at that. We disagree about the definition of a
bug, and I'll plan on adding the notification that one would expect!
> Check your attitude at home.
Pot-kettle. If you want help:
(1) Be polite
(2) Do your homework
(3) Don't expect free tech support to compensate for your laziness
(4) Don't call things bugs until you have verified that they are
indeed bugs
(5) Drop the entitled attitude and implication that others should
be writing better error notification code to suit your
specific needs
You're completely mistaking de-escalation and logical conversation as
entitlement... I'm really sorry you feel that way.
> Why are you doing your best to push new people away?
Because you still don't seem to get that your approach has been rude
and lazy from the get-go. I am happy to encourage users who are
respectful of other peoples time, who are willing to learn a little
and at least read the FAQ before asking for help, and who are
potentially willing to even give back.
BTW, you clearly don't seem to use much FOSS, especially
Enterprise-level. I wish I had a nickel for every time I encountered
so-called "attitude" when I would jump in as a newbie asking on some
Forum, for help without doing any prep work and without giving even
the most major of relevant background info.
I would highly recommend in the future, to not make wild and (usually
incorrect) assumptions about people. I've been using FOSS for about 30
years, contributing for 25 of those, various projects. Mainly writing c
for Asterisk these days. A bit of perl contributions to Postgres and
I've done a lot of FOSS php throughout the years. There goes your
assumptions out the window... your attitude comes across as narcissistic
and childish. But note how I've never made any blanket statements about
you as a person or jumped down your throat, even when you were blatantly
jumping down mine.
Let's compare apples to apples.
Typical IRC Conversation:
Me: "How do action X? Method xyz is not working for me"
Random User: First, try this.
However... using your model, the conversation would look like this:
Me: "How do action X? Method xyz is not working for me"
Kosowsky: OMG WHY DIDN'T YOU READ THE DOCUMENTATION???
Me: would you be able to point me to the right page on this?
Kosowsky: OMG WHY ARE YOU SO ENTITLED, THIS IS OPEN SOURCE SOFTWARE, NOT
WINDOWS
If you still fail to get why your attitude is so poor, then I'll just
leave it at this point. My theory is if I can affect good change,
definitely give it a try. But there's only so much one can do. Please
check out some of the other responses from other members of this list to
this same thread to get an idea of generally accepted 'good style' type
responses which some good models to go on for friendly conversation.
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
