Subject: Rename problem
To: None <tech-kern@NetBSD.ORG>
From: Wolfgang Solfrank <ws@tools.de>
List: tech-kern
Date: 05/27/1998 16:23:01
Hi,

While looking into PR 5468 (only related to msdosfs) I (among finding a few
other bugs in msdosfs) discovered a semantic problem with the way rename
works on filesystems that might store matching filenames in different ways.
The most common case for such filesystems are probably those that preserve
the case of the name when storing it to disk, but do filename matching
case-insensitive.

Now in this situation, what should the result of "mv a A" be?  One could
argue that the name on disk should be changed to the new form, ignoring the
fact that the new name would already match the file.

This however is impossible (ok, there might exist the possibility of some
gross hack to do it) to implement in a filesystem given the current
implementation of the POSIX rename system call (oh, btw, the comment
describing the difference between BSD rename and POSIX rename just above the
rename_files code in vfs_syscalls.c isn't correct in the light of this
either).

So, what exactly does POSIX have to say about rename semantics?  Would it
really forbid an implementation that did actually rename the file on disk
to the new name?

In case it doesn't (which I assume), in order to implement the semantics
described above, the retain argument to rename_files would have to be
delivered to the VOP_RENAME call to allow the filesystem to decide whether
to do anything or not.

Thoughts?

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800