stat.t fails at test #91 on AFS filesystem

[djzhh]

Module: op

Description

Making perl produces an error in t/op/stat.t while compiling on the local file system works w/o problems:

t/op/stat ........................................................ # Failed test 91 - -T _ doesn't break lstat for unreadable file at op/stat.t line 570
FAILED at test 91

NB: also errors for require_errors.t are produced; I'll open a separate issue for that

Steps to Reproduce

cd perl-5.38.2/perl-5.38.2/t
./TEST

The compilation takes place in an AFS filesystem.

The test must fail as there is no such thing as file-based ACLs in AFS; see https://docs.openafs.org/UserGuide/HDRWQ46.html

The failing test is

    550 # [perl #4253]
    551 {
    552     ok(open(F, ">", $tmpfile), 'can create temp file');
    553     close F;
    554     chmod 0077, $tmpfile;
    555     my @a = stat($tmpfile);
    556     my $s1 = -s _;
    557     -T _;
    558     my $s2 = -s _;
    559     is($s1, $s2, q(-T _ doesn't break the statbuffer));
    560     SKIP: {
    561         my $root_uid = $Is_Cygwin ? 18 : 0;
    562         skip "No lstat", 1 unless $Config{d_lstat};
    563         skip "uid=0", 1 if $< == $root_uid or $> == $root_uid;
    564         skip "Can't check if admin user in miniperl", 1
    565           if $^O =~ /^(cygwin|MSWin32|msys)$/ && is_miniperl();
    566         skip "Readable by group/other means readable by me on $^O", 1 if $^O eq 'VMS'
    567           or ($^O =~ /^(cygwin|MSWin32|msys)$/ and Win32::IsAdminUser());
    568         lstat($tmpfile);
    569         -T _;
    570         ok(eval { lstat _ },
    571            q(-T _ doesn't break lstat for unreadable file));
    572     }
    573     unlink $tmpfile;
    574 }

In line 554 a chmod is executed. As AFS does not have file-level permissions, the assumption in line 570 fails.

Example for the behaviour of AFS:

% mkdir demo
% cd demo

% fs listacl -path .
Access list for . is
Normal rights:
  username rlidwka
  system:administrators rlidwka
  system:anyuser l

% echo Hello World > a_file

% ls -ld a_file
-rw-r--r--. 1 username grp 12 Mar  6 02:34 a_file

% cat a_file
Hello World

% chmod 0000 a_file

% ls -ld a_file
----------. 1 username grp 12 Mar  6 02:34 a_file

% getfacl a_file
# file: a_file
# owner: username
# group: grp
user::---
group::---
other::---

% cat a_file
Hello World

% echo "Have a nice day" >> a_file

% cat a_file
Hello World
Have a nice day

Expected behavior
In the end there should be no errors in testing :)

Perl configuration
At this time during the installation of perl there is no Config.pm available to un perl -V

[djzhh]

What about skipping the test if $tmpfile is located in AFS?

I'm new to PERL tests, so this might all be wrong(ish)...

diff  stat.t_old stat.t_new
569,571c569,581
< 	-T _;
< 	ok(eval { lstat _ },
< 	   q(-T _ doesn't break lstat for unreadable file));
---
>   	SKIP: {
> 	        skip_if_miniperl("these modules may not be available to miniperl", 1);
> 		if ( !grep(/^\//,$tmpfile) ) {
> 		        require Cwd;
> 		        require File::Spec::Functions;
> 			$tmpfile = File::Spec::Functions::catfile(Cwd::getcwd(), $tmpfile);
> 		}
> 		skip "skipping this test in AFS $tmpfile",1
> 		  if grep(/^$Config{'afsroot'}/,$tmpfile);
> 		-T _;
> 		ok(eval { lstat _ },
> 		   "-T \_ doesn't break lstat for unreadable file");
>    	}

Well, if run in miniperl the test is skipped.

[jkeenan]

I have to confess that in 12 years of working on the Perl core distribution, I had never heard of the Andrew File System before encountering this ticket. So I'm wondering whether anyone has ever made an effort to explicitly port Perl to that platform. If not, should we attempt such a port? And if we did make such an attempt how would we keep it up to date?

[hvds]

I have to confess that in 12 years of working on the Perl core distribution, I had never heard of the Andrew File System before encountering this ticket. So I'm wondering whether anyone has ever made an effort to explicitly port Perl to that platform. If not, should we attempt such a port? And if we did make such an attempt how would we keep it up to date?

There have certainly been occasional mentions, even in that time. You'll see quite a few references to AFS in the code and docs (such as a mention in INSTALL dating back to 2004), evidence enough that the intention has been to support it for at least 20 years.

As for keeping support up to date, obviously life works best if we can get a regular smoke on AFS, but I don't know how likely that is. I think mentions of it have been rare partially because it has always been quite niche, and partially because it has tended to "simply work" such that little maintenance effort has been required.

[djzhh]

Yes, AFS is somewhat niche but quite firmly established at different institutions/companies. And my use case may be somewhat off-track, also. On most machines I use the Perl coming with the Linux distribution, but in this case I'd like to use it on a machine with lots of users and do not want to interfere with their (Perl) requirements and decided to use Perlbrew, thus stumbling upon those issues. And stat.t and require_errors.t are not alone in respect to AFS and file checks. After all it's only not passing the tests. I can see why and circumvent the issues by building Perl in a local filesystem and still have in my mind of what I have to think of concerning file operations on AFS within my Perl code. That's fine. And even better, there is a solution ahead -- thank you!

[jkeenan]

@djzhh, we have a pull request pending which may resolve this problem. Can you review #22076 and/or build and test it? Thanks.