Ideas for changes to Unix filesystem

[Barry Margolin]

In article <richard.665896415 at fafnir.la.locus.com> richard at locus.com (Richard M. Mathews) writes:
>With link() you have a pathname to the file, so you have some idea where
>you can put the new link().  Presumably with flink(), you are using this
>call because you DON'T have a pathname.  Since you don't know where the
>file came from, you have to do more work to figure out where it can go.

What do pathnames have to do with "where you can put the new link"?  You
can put the new link anywhere on the same file system as the file.  Due to
symbolic links, it is not possible to determine whether two files are on
the same file system simply by looking at the pathnames.

Presumably one of the first things that the link() system call does is
translate the old pathname to a device and inode (or vnode or whatever is
appropriate for the file system).  It then does the same thing for the
directory portion of the new pathname, and compares the device portion.
The device/inode information is presumably stored in the file table entry
that the file descriptor references, so the differences are trivial.  The
kernel code would presumably be structured something like:

link(const char *old_path, const char *new_path)
{
	file_info = namei(old_path);
	file_link(file_info, new_path);
}

flink(unsigned int fd, const char *new_path)
{
	file_info = lookup_fd_info(fd);
	if (file_info.device_type != file)
	    link_wrong_type_attempt();	/* can't flink a pipe, etc. */
	else
	    file_link(file_info, new_path);
}

file_link (FILE_INFO fi, new_path)
{
	device = get_pathname_device(new_path);
	if (device != fi.device)
	    cross_device_link_attempt();
	else
	    create_file(file_info, new_path);
}
--
Barry Margolin, Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar