[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch]gnu tar 1.19 canonicalize-lgpl_c.gdiff

From: John E. Malmberg
Subject: Re: [patch]gnu tar 1.19 canonicalize-lgpl_c.gdiff
Date: Tue, 01 Apr 2008 20:15:18 -0500
User-agent: Thunderbird (Windows/20080213)

Bruno Haible wrote:
John E. Malmberg wrote:
On VMS, think of "/<volume>/<directory/file", where <volume> can be any device mounted on the system, or logical name.

A logical name behaves like a symbolic link either in the current directory, or in the root directory as far as the file system is concerned, but it is stored in system memory, like an environment variable, so that logical names may restricted in scope.

It also means that they do not show up in reading a directory.

But this means that the lib/getcwd.c code will, in such cases, return NULL
and errno = ENOENT, no?

I have setup so that configure/make build results in the macro HAVE_PARTLY_WORKING_GETCWD being set.

Which means that getcwd() is called first, and the code to do the readdir() is only used if getcwd() fails.

The getcwd() call will properly handle paths with logical names.

And if getcwd() fails, the readdir code is not likely to work either.

When gnutar on VMS starts up, the first thing it does is set a C library feature switch that forces the getcwd() function to always return the path in UNIX syntax. Which means that passing the extra parameter to it to force the issue is not needed.

But GNU tar is just one program. There are dozens of other programs. And
there are also libraries, which don't have a "start up" phase. So the fix
belongs into lib/getcwd.c.

The feature switch applies only to the image that is using the C library, it does not affect anything else. All the switch does is change the default of the VMS C library to return names in UNIX syntax instead of VMS.

But yes, just about every program that is expecting a POSIX like environment does require this object module or similar to be linked in. But that now a trivial step to do on VMS.

And it also needs to be fixed in lib/canonicalize-lgpl.c because the
module 'canonicalize-lgpl' is under LGPL and therefore cannot depend on
the 'getcwd' module, which is GPL.

The only VMS specific code that was present before was an additional parameter to have the VMS getcwd() routine return the path in UNIX syntax, which because of the feature setting it would do anyway.

So I see no issue as far as VMS is concerned. If there is an issue with lib/canonicallize-lgpl calling rpl_getcwd, that is separate and not a VMS issue.

What do you think of this change? Is it correct? Would it allow you to
get rid of the startup hook that you mentioned?

It is not practical to get rid of the startup hook, but it's presence should not be a problem. Similar code is in Perl and Python.

Again, the thing to do is simply remove all the VMS specific code from canonicalize-lgpl. I fixed the code to compile, but I really should have just removed it.

I am starting a rebuild with the code removed to verify this.

I did put the following code in the module lib/gnv$getcwd.c_first below.
What it does is causes rpl_getcwd() to call it instead of the system getcwd(), and a replacement fstat() also to be used for a different reason, which I would have to look up.

What this solves is that the VMS getcwd() returns an error if you pass it a NULL buffer with a size of 0. So this routine detects this and changes it to be a call for a max size of 4097, which is the maximum size of a path on VMS, plus room for a trailing NULL.

This has been reported informally to HP for fixing, but I do not have any way of tracking the issue.

The CC program in the VMS build effectively pre-pends this module to lib/getcwd.c when it is built.

Personal Opinion Only

#define getcwd decc$getcwd
#define fstat hide_fstat
#include <vms_sys_library/stat.h>
#include <vms_sys_library/unistd.h>
#undef getcwd
#undef hide_fstat

#define decc_getcwd decc$getcwd

#pragma extern_prefix NOCRTL (getcwd, fstat)

int fstat(int fd, struct stat * statbuf);

char *
getcwd(char * buffer, unsigned int size, ...)
  int real_size;
  char * result;

    real_size = 0;
    if ((buffer == NULL) && (size == 0))
        real_size = 4097;

    result = decc_getcwd(buffer, real_size, 0);

    return result;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]