Searched hist:1930 (Results 1 - 10 of 10) sorted by relevance

/freebsd-10.1-release/usr.bin/ypcat/
H A DMakefile1930 Sun Aug 07 23:13:35 MDT 1994 wollman Move more YP user programs over.
H A Dypcat.11930 Sun Aug 07 23:13:35 MDT 1994 wollman Move more YP user programs over.
H A Dypcat.c1930 Sun Aug 07 23:13:35 MDT 1994 wollman Move more YP user programs over.
/freebsd-10.1-release/usr.bin/ypmatch/
H A DMakefile1930 Sun Aug 07 23:13:35 MDT 1994 wollman Move more YP user programs over.
H A Dypmatch.11930 Sun Aug 07 23:13:35 MDT 1994 wollman Move more YP user programs over.
H A Dypmatch.c1930 Sun Aug 07 23:13:35 MDT 1994 wollman Move more YP user programs over.
/freebsd-10.1-release/usr.bin/ypwhich/
H A DMakefile1930 Sun Aug 07 23:13:35 MDT 1994 wollman Move more YP user programs over.
H A Dypwhich.c1930 Sun Aug 07 23:13:35 MDT 1994 wollman Move more YP user programs over.
/freebsd-10.1-release/usr.bin/
H A DMakefilediff 1930 Sun Aug 07 23:13:35 MDT 1994 wollman Move more YP user programs over.
/freebsd-10.1-release/sys/ufs/ufs/
H A Dufs_vnops.cdiff 19388 Mon Nov 04 14:05:51 MST 1996 bde Fixed some races and misleading comments in ufs_rename().

1. When a directory is renamed to an existing (empty) directory,
it is possible for the target vnode to become the source vnode
underneath you (because another process may complete the same
rename). It was assumed that this can't happen, and the bogus
errno EINVAL was returned. This was fairly harmless.

Fix: return ENOENT instead, as if the source directory was renamed
a little earlier.

2. The same metamorphosis is possible for non-directories. It was
assumed that this can't happen, and the code for handling "just
removing a link name" happened to be used. This would have worked
except for fatal bugs in the link name removal - the link name was
assumed to still be there, and a null pointer was followed.

Fix: check the result of relookup(). This fixes PR 1930.

Notes:

(a) POSIX seems to say that removing link names shall have no effect.
BSD (4.4Lite2 at least) does something reasonable instead.

(b) The relookup() may find a file unrelated to the original.
Removing this isn't correct. Consider 3 existing files A, B and
C, and concurrent renames: AB = rename(A, B), another AB, and
CA = rename("c", "a"). If rename() is atomic, then only the
following results are possible:

AB, AB (fails), CA: A = original C, B = original A, C = gone
AB, CA, AB: A = gone, B = original C, C = gone
CA, AB, AB (fails): A = gone, B = original C, C = gone

but ufs_rename() can give:

A,AB,CA,B (sorta): A = gone, B = original A, C = gone

This usually doesn't matter, since getting into a race is usually
an error.
---

These fixes should be in 2.1.6 and 2.2.

Completed in 301 milliseconds