backup bouncer test suite
 

Hi,

Backup Bouncer is an independent backup test suite:

http://www.n8gray.org/blog/2007/04/2...ackup-bouncer/

Per this discussion, I know you are already aware of it, Dave:

http://www.shirt-pocket.com/forums/s...ead.php?t=3198

I was wondering three things:

1) Do you have plans to make the failing tests pass?

2) Can you describe scenarios where these things ("fifo" and "devices") might actually matter?

3) Do you have plans to contribute to and extend the test suite?

I am just curious about this. Obviously Super Duper! is the best choice ATM, and probably the two failing tests don't matter at all... it's more just a question about your development process and your quest for perfection.

Cheers,
Chris

We're aware of the fifos and devices not passing. It's something we'll look at in the future, but they -- unlike the other items -- tend not to be the kinds of things you'd want to copy.

Device entries in general shouldn't be copied (they're created and bound during the boot process).

FIFOs are used to allow multiple programs can communicate through a "pipe" -- they're usually created every time programs launch, and don't really have "meaning" across an execution (they don't even have any contents), so we decided not to handle them (they're kind of like VM swap files and temporary files, to our mind). It's really not clear what you should do with them, really.

I do not have plans to contribute to or extend the suite at present, at least: we have our own testing tools that we've developed internally, but they're not things we'd want to release to the public (and our competitors).

That's true for devices, but FIFOs should be recreated or ignored (and the fact that it was ignored logged) otherwise things that depend on the FIFO's behavior tend to break in very strange and hard to diagnose ways.

That's not strictly true. FIFOs are often used to allow asynchronous communication between processes and often should be retained between executions. In fact, they're usually only created when persistence is desired -- otherwise there are other, more efficient, mechanisms available.

Here's a (real) example:

Say I want to know what a system process is doing by reading its log and performing some action based on that. I can configure syslog to record that daemon's process to a FIFO in addition to the standard log files, then point my process at the fifo and parse the byte stream as I get it, allowing me to do what I need to do without hacking the daemon or executing my process in a privileged mode. Since I want my process to run at startup and I don't really have much control of when it starts relative to the syslogd or the daemon process I'm watching, the FIFO needs to be persistent. Otherwise syslogd will create it as a standard file and my process will be SOL when it tries to open it.

Very useful.

Oh, and put my vote in the "I'd really like to see FIFOs copied correctly" bin. Thanks!

The point is understood (although I'd argue you'd typically create this FIFO during startup); as I've said elsewhere, we're going to be recreating FIFOs and devices (outside /dev, of course) this in the next update.

I could, but I'd have to do it before syslogd gets started, meaning a more intrusive modification than I'd like to make -- and the more likely it will be that Apple hammers it in an update.

Still, the point I was making was that, since it's not really possible to know why the pipe was created or what it's being used for, I'd be inclined not to mess with it, and either duplicate it faithfully or ignore it and report the fact. Changing it into a normal file is not desirable.

Great! Thanks!

We don't actually change it into a normal file; it's skipped in the current version, although no report is made as I recall.

Does it? Okay. It seems to me an earlier version (2.1.4?) just copied them as normal files and I assumed that 2.5 handled things the same way since there wasn't a mention of it in the version history. I've got SD! set up to run a script that fixes my FIFOs for me, so I'll have to disable that and give it a try. Thanks!

Hi Dnanian,

When roughly do you expect the next major release to be available?

There's not even the slightest hint of what's happening on the front page of your website..

I've held back buying in the past, but I'll be reaching for my wallet this time round!

If it comes out within a reasonable time-frame..

Cheers,
Jed

We don't announce these things until they're ready, Jed, sorry. I'm not sure why the fact that an update has not been announced would prevent you from registering now. Have we ever charged for an update so far?

(That isn't to say we'll never charge for an update, just that we never have over the past, what, five years?)

I've just not used the product mate..
I'm a lot more committed to using a product it if I've paid for it, but..

I don't wont to pay for 2.5 only to be told shortly afterwards that a major new release is available "for a small upgrade fee".
I'd rather just pay for the major new release when it's available!

Can we expect a release this year, the latter half of next year, or later...
Large time windows are fine, don't have to give us an exact month etc.

-jed.

Sorry: can't give a date. But as I said, we have never charged for an update, right?

Lame, will prolly buy 2.5 then...

But I'll be peeved if I have to pay all over again.
Especially if it's this year..

tnx,
-jed.

Lame? It's hard to understand how "every update that we've ever released, from 1.0 until 2.5, has been completely free to every user, and that we offer significant functionality that's been entirely free, with support, during all that time" is "lame", but everyone's entitled to their opinion, I guess, Jed! :)

I was referring to the 'smoke n mirrors' with regards to release time-frame, nothing more.

I want the extra support/functionality, hence I have no problem with paying.
I just don't like buying into something when I have no way of knowing if there's a major update around the corner.

Especially if I have to pay again to get the 'new' extra functionality..

-jed.

We just don't do "smoke and mirrors", Jed. Sorry: I don't think it benefits anyone.

Dnanian, let me be more clear... What I meant by "smoke n mirrors is"...
Your developmental model is a lot more "under wraps" compared to other projects.

That's fine and entirely your choice...
Just be clear as early as possible what your plans are for the next major paid for release.

Otherwise you risk alienating people..