At 11:40 PM -0500 3/3/05, John E. Malmberg wrote:
Building an on-the-fly program, usually called try.c, is the standard
way to go. There are quite a few examples in configure.com. There
is no reason to even run the test on VAX or on non-VAX prior to
v7.3-1.
I will see about writing such a program for hard links being enabled, right now, I can only easily test it on 8.2.
What do you need for a patch to be submitted?
GNU unified diffs of any files that have changed would be ideal. It's not clear to me to what extent the various changes you have in progress can be separated out, but I'm willing to help with the separating if you have something we can go ahead and get into bleadperl. I'm assuming configure.com, [.vms]vmsish.h, and [.vms]descrip_mms.template at a minimum are involved.
Actually as I posted before, there are two modules utils/c2ph.pl, x2p/pl, involved that you provided a better change to, and a change to configure.com to enable hard links.
No changes to vmsish.h or descrip_mms.template are needed.
It may be better to change the .PM modules so that for the VMS platform they can detect if hard links are available on the target, or detect that the link() call fails, they then fall back to the copy, and have the hard link test also skip that tests when hard links are not available.
That way perl can be built with hard link support even on disks that do not support hard links.
The only real outstanding issue for me with hard links is that the perl umask function is not working as expected, and this is only effectively tested if hard links are enabled.
It looks like that perl test [.t.io]fs.t is wrong. It should be testing to see if the first file protection mask matches the what was set by the umask() call, even when hard links are not enabled.
Then it should be checking to see that the triply linked file has the same umask as the original if hard links exist
I probably will not have time to find out why the perl umask code is not working as expected for a little while as that appears to be an existing bug.
It also appears that umask issues are present on other platforms as there are special case codes in the test.
I will see what I can do to get some patches for bleadperl.
Actually there really should not be any reason not to enable large file support when it is available.
I think it's slower, and also we try to track whatever defaults the
> unix builds use.
I do not see why it would be slower, it is probably just alternate inputs to the same I/O routines with larger data types for the transfers.
Are the UNIX builds not auto-enabling large file support when they detect that it is available?
-John [EMAIL PROTECTED] Personal Opinion Only
