bug-gnulib
[Top][All Lists]
Advanced

[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 08:55:53 -0500
User-agent: Thunderbird 2.0.0.12 (Windows/20080213)

Bruno Haible wrote:
Jim Meyering wrote:
How about the patch below instead?
I've moved the prototype down, so that we see
the offensive, "$"-containing symbol name only once ;-)

It is less understandable than John Malmberg's patch, because
  - normally you should have a declaration of a function before you start
    using it,
  - gnulib has a declaration of __getcwd also in lib/getcwd.c, and it's a
    different function.

But what the patch does appears wrong to me anyway: It says that
  - there is a system function getcwd,
  - there is also a system function decc$getcwd,

On VMS, all the system functions start out with decc$. The compiler uses a table to know what they are and automatically adds the prefix, unless macro substitution is active.

Gnulib does the macro substitution, so the real prefixed symbol name is used to get around that.

  - there is also a gnulib rpl_getcwd,
  - the rpl_getcwd does not work as well as decc$getcwd.

The last point is understandable, since (IIRC, someone said) on VMS there are
several root directories and going up with ../, ../../, etc. will most often
lead to the wrong one.

Actually that will normally do the expected on VMS.

However looking for "/" on VMS is not safe because usually there are multiple disjoint "/". And doing a readdir on "/" will not usually show up all the files that will open with "/" prepended to them.

In some cases there is a simulated "/" directory tree, but again, it usually will not show everything that can be accessed using "/" in front of the name.

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.

Most well run VMS installations use logical names extensively and usually as the preferred (required) way to locate files that on UNIX would be under "/".

The action to do in this situation is to make gnulib's rpl_getcwd work
better, not work around it in many other source files. Keep all getcwd
related changes in lib/getcwd.c, m4/getcwd.m4, lib/unistd.in.h.

John, can you do that?

Actually after having a sleep on the issue, it would probably be best to simply remove the VMS specific code from canonicalize-lgpl.c.

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.

-John
address@hidden
Personal Opinion Only




reply via email to

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