backup bouncer test suite

[Chris Pickett]

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

[dnanian]

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).

[jtk]

Originally Posted by dnanian

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.

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.

[FIFOs] 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).

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!

[dnanian]

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.

[jtk]

Originally Posted by dnanian

although I'd argue you'd typically create this FIFO during startup

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.

we're going to be recreating FIFOs and devices (outside /dev, of course) this in the next update.

Great! Thanks!

[dnanian]

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.

[jed]

Originally Posted by dnanian

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.

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

[dnanian]

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?)