Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Oct 2000 17:59:33 +0000
From:      pdp@nl.demon.net
To:        FreeBSD-gnats-submit@freebsd.org
Cc:        pdp@nl.demon.net
Subject:   bin/22291: getcwd() fails on recently-modified NFS-mounted dirs
Message-ID:  <E13oUpp-0001q9-00@ftp.server.nl.demon.net>

next in thread | raw e-mail | index | archive | help

>Number:         22291
>Category:       bin
>Synopsis:       getcwd() fails on recently-modified NFS-mounted dirs
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Oct 25 11:00:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Phil Pennock
>Release:        FreeBSD 4.1.1-STABLE i386
>Organization:
Thus PLC (Demon NL)
>Environment:
FreeBSD FreeBSD 4.1.1-STABLE i386 (src upgraded 2000-09-29)
NFS mount from Network Appliance Netapp
ftp-netapp1:/ftp on /public/pub (nfs, nodev, nosuid)
>Description:
We have an FTP server, mounting publically-available filesystem from a
NetApp.  The chroot() point is to local disk, with NFS mounted on /pub
within that environment.  With an open FTP connection, the (customised)
server experiences a realpath() failure (EACCESS) if the cwd of the
connection is modified (file added or deleted) via normal login.  This
resolves itself either with the passing of time, or by causing a stat of
the directory which isn't stat(".") (CDUP, CD back; or "ls /the/cwd").
The call to realpath() fails in getcwd() (found via gdb).

Using ktrace, we see:
  6506 ftpd     CALL  __getcwd(0xbfbff2ec,0x400)
  6506 ftpd     RET   __getcwd -1 errno 20 Not a directory

This is a directory; it has just been modified recently.

ktrace's of an FTP LIST command when it works and when it fails because
the dir has been modified available upon request.  A "diff -u" is
informative.
>How-To-Repeat:
Via Description above.  ktraces, diffs, available upon request.  Access
to server code can be arranged if desired, but the above shows it to not
be a problem with our code.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E13oUpp-0001q9-00>