Re: A filesystem philosophy question

You (Andrew Valencia) wrote:
>
> [larz@world.std.com (Mike A Larson) writes:]
>
> >> If, in fact,
> >> both files are in the same filesystem, I guess you could trim off everything
> >> except the filesystem-relative part and pass that. But this doesn't seem
> >> like a very good solution. ...
> >Why isn't this a very good solution for intra-filesystem renames (ie,
> >renames within the same filesystem partition or name space)? As a matter
> >of fact, why isn't this the best solution for the case where both
> >the source and destination files reside in the same directory (eg,
> >mv foo bar) and the rename consists of simply changing the file's
> >directory name entry(s)?
>
> Recall that the path lookup loop is not encoded in the server. Why add
> an entire new mechanism to servers to solve an edge case?
>
> But this *has* brought to mind an issue I hadn't considered. What to
> do about filesystems where there is a many->one relationship of directory
> entries to files? You'd either have to record the path in the open file
> state (talk about new mechanism) or something equally expensive.

No. The logical way to implement a rename is in my opinion the
following:

Open the directory where the file (or whatever) is. Open the directory
where it should be. Call the rename function with the two open
directories and the old and the new name as parameters. This works on
file systems with several links per file as well.

        hp

-- 
   _  | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems
|_|_) |------------------------------------------------------------------------
| |   | It's not what we don't know that gets us into trouble, it's
__/   | what we know that ain't so. -- Will Rogers