Re: kern/59076: File is silently removed when renaming on msdos filesystem when mounted with -l

["David Holland via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/59076; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/59076: File is silently removed when renaming on msdos
 filesystem when mounted with -l
Date: Fri, 14 Feb 2025 23:00:43 +0000

 On Fri, Feb 14, 2025 at 10:05:00PM +0000, triaxx%netbsd.org@localhost wrote:
  > I have a msdos filesystem mounted with:
  >     # mount -tmsdos -orw,-U,-l,-M755,-m644
  > 
  > I try to rename a file from uppercase to lowercase:
  >     # cd /mnt/boot/EFI/NETBSD
  >     # mv BOOT.CFG boot.cfg
  > 
  > The file BOOT.CFG is silently removed.
 
 So the reason for this is that rename checks for whether you're trying
 to rename a file over itself, and unless you enable the POSIX_MISTAKE
 version it does this by examining the filename with memcmp.
 
 So on all case-insensitive, case-folding, unicode-normalizing, etc.
 filesystems it will sometimes get wrong answers, not engage the
 special-case logic that protects against this behavior, and delete the
 file.
 
 The logic in question is at line 309 of genfs_rename.c:
 
 		else if ((fdvp == tdvp) &&
 		    (fcnp->cn_namelen == tcnp->cn_namelen) &&
 		    (memcmp(fcnp->cn_nameptr, tcnp->cn_nameptr,
 			fcnp->cn_namelen) == 0))
 			/* Renaming an entry over itself does nothing.  */
 			error = 0;
 
 This needs to be able to call a fs-specific compare function instead.
 Which is going to be a right pain, I think. The only real way to do it
 is to add a name compare function to some ops table; the main question
 I think is whether to add it to genfs_rename_ops (sufficient to deal
 with this problem) or put it in struct vfsops where it can be used in
 other contexts.
 
 I'm worried what kind of silly things the namecache might get up to
 without also having this hook, especially given that everything
 relating to invalidation and housekeeping in the namecache is very
 squirrelly.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost