--G3juXO9GfR42w+sw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 25, 2004 at 10:37:20PM +0200, uwe@6bone.informatik.uni-leipzig.=
de wrote:
> hello,
>=20
> if you mount an nfs directory from a SFU 3.5 nfs-server you cannot
> execute a "rm -rf" command at a non-empty directory. the error code is
> ERR_NOTEMPTY. if you try "rm -f" all works well.
>=20
> example at a SFU directory:
>=20
> mkdir -p foo/foo/foo
> rm -rf foo --> Error
> rm -f foo  --> work fine

You mean rm -r foo ?? rm -f complains that foo is a directory.

> the microsoft support tells me the following:
>=20
> #######################################################
>=20
> So the issue here is that you're seeing this problem on SFU 3.5 NFS Serve=
r? Or
> is it still SFU 2.3? For the record, we don't test with NetBSD at all.
> Only supported flavors are HP-UX, AIX, Solaris and RH Linux.
>=20
> Your network traces tell me that nothing is wrong with NFS Server. The two
> captures where you have the rm succeeding show that the directory
> hierarchy is like this - .\foo\foo\foo and these 4 directories have
> handles like 000A - C522 - C622 - C722.
>=20
> If you look at the traces closely, the two cases where the experiment
> succeeded show that you rightly get three RMDIR (remove directory) calls
> in the order C722 - C622 - C522 and everything is as expected.
>=20
> In the failure trace, you see that the client knows that the directory
> hierarchy is like 000A - C5222 - C622 and is never sending an RMDIR on
> C622 but is sending a RMDIR directly on C522. This is rightly failed by
> the NFS Server with ERR_NOTEMPTY.
>=20
> Seems to me like the client is goofing up here
>=20
> #############################################################
>=20
> Can anyone confirm, if it is really a NetBSD nfs problem?
> In the other case I will call the microsoft support again.

I assume that multiple "rm -rf foo"s in a row each fail? Or rm -f after=20
the mkdir works?

This is weird, as in my testing both cases worked fine.

Take care,

Bill

--G3juXO9GfR42w+sw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAtVSlWz+3JHUci9cRApWZAJ0fq56GZ39JanM93xb+90dPxL31MgCglxDF
uODhcki8pKl9czBzYuqwW+c=
=CvkF
-----END PGP SIGNATURE-----

--G3juXO9GfR42w+sw--