[Box Backup-dev] COMMIT r299 - in box/trunk: . infrastructure lib/backupclient test/raidfile

[Ben Summers]

On 5 Jan 2006, at 23:22, Martin Ebourne wrote:

> On Thu, 2006-01-05 at 23:01 +0000, Ben Summers wrote:
>> This affects the xattr support code -- can someone test it on Linux?
>
> Yep, I'll install it on mine. The changes look very safe, anyhow.

Thanks.

>
>> (I am a little concerned there is no automated test for this
>> functionality... unless I've missed it somehow.)
>
> No, there isn't, as I said originally (thought that was a while ago
> now!).
>
> I would like tests for it and am happy to write them, but  
> unfortunately
> I don't think they'd get run. The problem is that in order to use  
> xattrs
> on Linux the filesystem has to be mounted with the user_xattr  
> option. So

Do you get ENOTSUP if you try and set them when they're not enabled?

> they could only be run if the filesystem box was compiled on was  
> mounted
> in this way. At the moment I think this is probably quite rare
> generally, though I guess it will become increasingly common with
> selinux and programs such as Beagle.
>
> File acls are also implemented internally using xattrs but again they
> need an acl mount option, and would be even harder to write a portable
> test for. So far I've just tested manually which is not ideal.
>
> Are they enabled for everyone on Darwin?

Yes.

> If so maybe it would be worth
> writing a test because at least one platform would always run them. :)

I'll write a simple test this morning, and then you can verify and  
extend it. It's nice to have a test written by someone who didn't  
write the original code.

>
>> I have also removed the non-functional intercept code for Darwin,
>> which won't work on Intel anyway so is best left out. But this brings
>> me onto another issue; it appears that the test/raidfile code for
>> testing what happens when the OS reports errors reading files is
>> disabled on most, if not all, platforms. What is the reason for
>> excluding it? I'm not entirely sure I follow the autoconf logic.
>
> I'm not sure exactly what you mean. If you mean
> PLATFORM_CLIB_FNS_INTERCEPTION_IMPOSSIBLE and TRF_CAN_INTERCEPT  
> then as
> far as I know they are only set if large file support is active. Which
> probably is most platforms these days. I'm sure this is something you
> did in 0.09 because intercepts didn't work with large file support for
> some reason.

Ah, I understand what's happened. Indeed, interception is disabled if  
large file support is active, but large file support is a Linux only  
thing. On other platforms, large files are not a recent innovation  
and never needed anything special to be done.

So, what's the best autoconf way of making this all Linux only?

Ben