>Number:         10235
>Category:       kern
>Synopsis:       null (loop-back) fs mounted over NFS leaves .nfs* files untouchable
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 30 08:36:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Greg A. Woods
>Release:        Mon Mar 20 09:47:15 EST 2000
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:

System: NetBSD 1.4V i386

>Description:

	I have a loop-back mount using the "null" fs layer to facilitate
	getting an NFS filesystem into the right point for a chroot'ed
	application (ftpd).

	When I create new files and directories in the loopback view of
	the filesystem I cannot immediately remove the new
	sub-directories because .nfs* files are created for each new
	file which cannot be removed from either the loopback layer
	view, or the NFS mount point view.

	This does not happen when the same operations are done within
	the NFS mount point.  Given the comments received on
	current-users I suspect this problem is due to some nasty tricks
	the NFS filesystem might be playing behind the null filesystem's
	back.

>How-To-Repeat:

	# create the scenario described above

	$ /sbin/mount
	/dev/sd0a on / type ffs (NFS exported, local)
	/dev/sd0e on /var type ffs (NFS exported, local)
	/dev/sd1a on /altroot type ffs (NFS exported, local)
	/dev/sd4h on /backups type ffs (local)
	/dev/sd1e on /tmp type ffs (NFS exported, local)
	/dev/sd0f on /cvs type ffs (local)
	/dev/sd1f on /opt type ffs (NFS exported, local)
	/dev/sd2h on /work type ffs (NFS exported, local)
	most.weird.com:/big1 on /most/big1 type nfs
	most.weird.com:/netbsd-1.4 on /most/netbsd-1.4 type nfs
	most.weird.com:/spare on /most/spare type nfs
	most.weird.com:/var on /most/var type nfs
	kernfs on /kern type kernfs (local)
	procfs on /proc type procfs (local)
	fdesc on /fdesc type fdesc (local)
	/most/var/spool/ftp/pub on /var/spool/ftp/pub type null

	# go into the loopback view and create some new files and
	# directories; by unpacking a tar file, for example

	$ cd /var/spool/ftp/pub/mirror
	$ pax -rzf somearchive.tar.gz
	$ rm -rf somearchive

	# observe "rm" complain about "Directory not empty" for ever
	# directory created by the unpacked archive

	$ ls -la somearchive
	[[ lots of .nfs* files not shown here ]]

	# observe that there are .nfs* files remaining in the new
	# subdirectories that cannot be removed from the loopback
	# hierarchy.

	# now go and try to remove them from the NFS view
	
	$ cd /most/var/spool/ftp/pub/mirror/somearchive
	$ rm -f .nfs*
	$ ls -la
	[[ lots of .nfs* files not shown here ]]

	# note that rm doesn't complain about not being able to remove
	# the files (unlink() must be returning success), but that they
	# are still there....

	# now prove that from the NFS view all is well:

	$ cd /most/var/spool/ftp/pub/mirror
	$ pax -rzf someotherarchive.tar.gz
	$ rm -rf someotherarchive
	$ ls -la someotherarchive
	ls: someotherarchive: No such file or directory

	# also observe that "df" sees right through the loopback layer
	# when maybe it should not:

	$ df /var/spool/ftp/pub
	Filesystem              512-blocks     Used    Avail Capacity  Mounted on
	/most/var/spool/ftp/pub    2819610  2358416   320212    88%    /var/spool/ftp/pub

>Fix:

	none known (rewrite the NFS filesystem "properly"? :-)
>Release-Note:
>Audit-Trail:
>Unformatted: