Case changing silently breaks on case-insensitive FS

[particleflux]

Tick this box to confirm you have reviewed the above.

• I've discovered a new issue with F2.

What version of F2 are you using?

f2 version 2.1.1
https://github.com/ayoisaiah/f2/releases/2.1.1

How did you install F2?

GH binary

What operating system are you using F2 on?

Gentoo / Linux 6.14.6

Describe your bug.

Case changing silently breaks on case-insensitive FS.
Trying to rename a file and only changing the case on a mounted CIFS/Samba share aka a case-insensitive FS does report OK but silently fails in the middle of the renaming operation.

The mounted FS has these options:

type cifs (rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,addr=192.168.178.222,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,reparse=nfs,nativesocket,symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)

What are the steps to reproduce the behavior?

• mount a CIFS FS
• rename a file there, e.g.

touch FOO
f2 -f FOO -r Foo 
f2 -f FOO -r Foo -x

What behaviour did you observe?

• file is renamed to a temporary name
• f2 reports "everything OK" regardless
• undo won't work since it thinks all is OK

$ ls -la
total 4.0K
drwxr-xr-x 2 stefan stefan 0 May 25 12:08 .
drwxr-xr-x 2 stefan stefan 0 May 25 12:06 ..
-rwxr-xr-x 1 stefan stefan 0 May 25 12:06 FOO

$ f2 -f FOO -r Foo -V
*——————————*—————————*————————*
| ORIGINAL | RENAMED | STATUS |
*——————————*—————————*————————*
| FOO      | Foo     | ok     |
*——————————*—————————*————————*
dry run: commit the above changes with the -x/--exec flag

$ f2 -f FOO -r Foo -V -x
renamed: 'FOO' to 'Foo'

$ ls -la
total 4
drwxr-xr-x 2 stefan stefan 0 May 25 12:08 .
drwxr-xr-x 2 stefan stefan 0 May 25 12:06 ..
-rwxr-xr-x 1 stefan stefan 0 May 25 12:06 __1748167688837658691__Foo__1748167688837658691__


$ f2 -u
*——————————*—————————*——————————————————*
| ORIGINAL | RENAMED |      STATUS      |
*——————————*—————————*——————————————————*
| Foo      | FOO     | source not found |
*——————————*—————————*——————————————————*
conflict: resolve manually or use -F/--fix-conflicts

As a comparison, this is what mv does

$ mv BAR Bar
mv: 'BAR' and 'Bar' are the same file

What is the expected behaviour?

It should probably abort with a conflict, since the files are the same.

[ayoisaiah]

@particleflux Thanks for raising this. The temporary name is used here to enable case renaming on case-insensitive FS, but so it should have gone like this:

FOO -> __1748167688837658691__Foo__1748167688837658691__ -> Foo

This works in FAT32 for example:

I'm not sure why it failed on your setup, but I'll try to reproduce it and investigate further.

[particleflux]

Knowing what should happen, I cloned the repo and tried to debug a bit, but things get even more wild.

I added some debug printfs there and they all are OK

		err := os.Rename(ch.SourcePath, targetPath) // step 2
		fmt.Println(ch.SourcePath, ch.TargetPath, err)
		// if the intermediate rename is successful,
		// proceed with the original renaming operation
		if err == nil && isCaseChangeOnly {
			fmt.Println(targetPath, ch.TargetPath, err)
			err = os.Rename(targetPath, ch.TargetPath) // step 3
		}

Yet:

test $ ~/src/f2/f2 -f FOO -r Foo -x
FOO Foo <nil>
__1748245387382315428__Foo__1748245387382315428__ Foo <nil>

test $ ls
__1748245387382315428__Foo__1748245387382315428__  BAR

Even more fun, I did an strace, and that shows the second os.Rename succeeded at syscall level:

renameat(AT_FDCWD, "FOO", AT_FDCWD, "__1748245419898812607__Foo__1748245419898812607__") = 0
write(1, "FOO Foo <nil>\n", 14FOO Foo <nil>
)         = 14
write(1, "__1748245419898812607__Foo__1748"..., 60__1748245419898812607__Foo__1748245419898812607__ Foo <nil>
) = 60
newfstatat(AT_FDCWD, "Foo", {st_mode=S_IFREG|0755, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
renameat(AT_FDCWD, "__1748245419898812607__Foo__1748245419898812607__", AT_FDCWD, "Foo") = 0

Yet, it still is not renamed.

This is starting to look like an issue in either the CIFS driver or the remote system (it's mounted of a QNAP NAS). Might do a bit more digging when I next have time.

UPDATE

Trying to mv to rename the last step does:

$ mv __1748245419898812607__Foo__1748245419898812607__ Foo
mv: '__1748245419898812607__Foo__1748245419898812607__' and 'Foo' are the same file

Yet, I can go back to FOO with

$ mv __1748245419898812607__Foo__1748245419898812607__ FOO

[particleflux]

Got it.

Setting CIFS mount options noserverino fixes the issue. (See https://linux.die.net/man/8/mount.cifs)
Seems the fast consecutive renames lead to reused inode numbers otherwise.

Not sure how to correctly catch or prevent this issue tho

On a side note, the same issue exists when renaming one file twice with mv

$ mv FOO _foo
$ mv _foo Foo
mv: '_foo' and 'Foo' are the same file