Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3EA435FE.D15313E1@phekda.freeserve.co.uk>
Date: Mon, 21 Apr 2003 19:18:38 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: fstat, fd_props and inventing inodes, revision 3 [PATCH]
References: <E196rAk-0007Mp-00 AT phekda DOT freeserve DOT co DOT uk> <003101c30704$8dbb1ea0$0100a8c0 AT acp42g> <3EA2670B DOT C1014D39 AT phekda DOT freeserve DOT co DOT uk> <1190-Sun20Apr2003135401+0300-eliz AT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Sun, 20 Apr 2003 10:23:23 +0100
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> >
> > They are expected. IIRC not all the DJGPP library functions support UNCs.
> > The fileutils code is not aware of UNCs. So 'ls' should not be expected
> > to work with UNCs.
> >
> > fstat, however, does work on UNCs.
> 
> If `fstat' supports UNCs, but `stat' does not, it is IMHO a bug that
> we ought to fix.

I think 'stat' used to support UNCs. I recall testing it: when I was working
on unc_fsx, you pointed out that some library functions already supported and
UNCs and I believe stat was the one.

There appears to be a problem with _fixpath regarding UNCs:
__canonicalize_path does not support UNCs.

I think we need to add a test suite for __canonicalise_path, to check that it
works with all the weird paths we can come up with.

I'll add a work item to the 2.04 status page.

> > I suppose the patch may not work correctly, if the user opens the file
> > using the UNC, then maps it to a drive later. In that case fstat'ing
> > before and after the mapping will give different inodes. The same is true
> > if the UNC mapping is changed to a different drive letter. But I think it
> > is unlikely in practice that the mappings will change during the course
> > of program execution.
> 
> If the drive mappings are changed during the program's execution, I
> think the file descriptor is no longer valid.  Perhaps someone could
> try this and see whether I'm mistaken.

Yes, it does. Below is t-unc.c. If you change the mapping while the program is
sleeping, the second filelength call will fail with errno == EINVAL.

Bye, Rich =]

---Start t-unc.c---
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <io.h>

int
main (int argc, char *argv[])
{
  const int HOW_SLEEPY_AM_I = 20;
  const char *file;
  int fd;

  if (argc < 2)
    {
      fprintf(stderr, "Syntax: %s <file>\n", argv[0]);
      return(EXIT_FAILURE);
    }

  file = argv[1];

  fd = open(file, O_RDONLY);
  if (fd < 0)
    {
      perror(argv[0]);
      return(EXIT_SUCCESS);
    }

  if (filelength(fd) == -1L)
    {
      close(fd);
      perror(argv[0]);
      return(EXIT_SUCCESS);
    }

  printf("Sleeping for %d seconds - please change the UNC mapping (if
any)!\n",
	 HOW_SLEEPY_AM_I);
  sleep(HOW_SLEEPY_AM_I);

  if (filelength(fd) == -1L)
    {
      close(fd);
      perror(argv[0]);
      return(EXIT_SUCCESS);
    }

  close(fd);

  return(EXIT_SUCCESS);
}
---End t-unc.c---