By default, tempfile creates in cwd, which could easily be on NFS.
David
On Feb 2, 2013 3:08 PM, "Serguei Trouchelle" <s...@cpan.org> wrote:
> Gabor Szabo wrote:
>
>> If a real world user can also have similar setup using NFS, then this is
>> a legitimate setup, isn't it?
>>
> I can hardly imagine a real system with /tmp being on NFS, but yes, it's
> possible, and I don't argue with this. My point is, once problem is found,
> do authors need more reports with the same issue if this issue has nothing
> to do with the module functionality? I think no. Problem appears when I
> call Test::Script::script_compiles, it calls IPC::Run3, which in turn calls
> File::Temp, and "unlink0" function cannot guarantee actual removal of file
> on NFS. "script_compiles" is a very basic sanity check and if it fails,
> then something is absolutely wrong.
> Yes, most likely, Test::Script should have a test for this and refuse to
> install, but I don't see how *I* can do something about it.
>
>> Isn't this exactly the same situation as Windows vs Linux, where
>> Windows might not support all
>> the features Linux does?
>>
> Not really. If module fails on Windows, it fails every time "make test" is
> executed on Windows machine.
> If module cannot be compiled on this machine (because of missing library
> or something), it will get UNKNOWN grade. It's not the same situation.
> I'm fine with getting UNKNOWN. I'm not fine with getting FAIL when it's a
> problem with testing infrastructure that my modules are not using during
> real-world tasks.
>
>> Are those only test failures, or is the module (partially) broken on a
>> system using NFS?
>>
> Which module? If you're talking about my module, it's not.
> File::Temp, which is used by *test* harness, is somewhat broken.
> That's my point, when problem is found and located, then affected smoker
> should be stopped to prevent entropy increase.
>
>> If the module does not fully work over NFS then shouldn't it recognize
>> the situation
>> and disallow those features?
>>
> Well, you cannot actually know is it NFS or not on when rusing library
> interfaces without hacks. And I don't like hacks.
>
>> If only the tests fail on NFS, shouldn't those be skipped?
>>
> The only way I see it's skipped is to skip when $ENV{'HOME'} =~
> m!^/home/njh! but it's extremely counter-productive. I'd rather live with
> false positives :)
>
> --
> S.T.
>
>
