How to reproduce: > $ mkdir A && mv A B The operation succeeds but listing the contents of the root warns about stale file handle for B. > $ mkdir A B && mv A B The mv operation fails - device or resource busy. Running both of these test cases in a subdirectory to the export root works as expected.
Comment #11 from bug 2180 is relevant, so copying it here: For the curious, here's a couple of strace/dtruss logs: strace of mv on the ThinLinc server side (unfsd client side). > execve("/bin/mv", ["mv", "Untitled Folder/", "Untitled Folder 2"], [/* 45 vars */]) = 0 > [...] > stat("Untitled Folder 2", 0x7fff9934a7f0) = -1 ENOENT (No such file or directory) > lstat("Untitled Folder/", {st_mode=S_IFDIR|0775, st_size=68, ...}) = 0 > lstat("Untitled Folder 2", 0x7fff9934a590) = -1 ENOENT (No such file or directory) > rename("Untitled Folder/", "Untitled Folder 2") = -1 EBUSY (Device or resource busy) > [...] dtruss output from tracing unfsd on OS X 10.8 (same operation as above). > 13595/0x6b2f3: 515245 454989 63 select_nocancel(0x400, 0xBFFFFA94, 0x0) = 1 0 > 13595/0x6b2f3: 515290 9 2 select_nocancel(0x6, 0xBFFFF2D8, 0x0) = 1 0 > 13595/0x6b2f3: 515294 7 3 read_nocancel(0x5, "\200\0", 0xFA0) = 132 0 > 13595/0x6b2f3: 515368 248 66 lstat("/Users/aaron\0", 0x4C8BF0, 0xFA0) = 0 0 > 13595/0x6b2f3: 515396 30 24 open_nocancel("/Users/aaron\0", 0x1120004, 0x0) = 4 0 > 13595/0x6b2f3: 515404 7 3 fstatfs(0x4, 0xBFFFF118, 0x0) = 0 0 > 13595/0x6b2f3: 515434 31 27 getdirentries(0x4, 0xBC7A00, 0x1000) = 492 0 > 13595/0x6b2f3: 515441 7 4 getdirentries(0x4, 0xBC7A00, 0x1000) = 0 0 > 13595/0x6b2f3: 515445 5 2 lseek(0x4, 0x0, 0x0) = 0 0 > 13595/0x6b2f3: 515453 8 4 close_nocancel(0x4) = 0 0 > 13595/0x6b2f3: 515458 3 0 getuid(0x4, 0x0, 0x0) = 502 0 > 13595/0x6b2f3: 515459 3 0 getgid(0x4, 0x0, 0x0) = 20 0 > 13595/0x6b2f3: 515463 5 3 lstat("/Users/aaron\0", 0xBFFFF210, 0x0) = 0 0 > 13595/0x6b2f3: 515485 20 16 write_nocancel(0x5, "\200\0", 0x7C) = 124 0 > 13595/0x6b2f3: 515502 932 9 select_nocancel(0x400, 0xBFFFFA94, 0x0) = 1 0 > 13595/0x6b2f3: 515510 4 1 select_nocancel(0x6, 0xBFFFF2D8, 0x0) = 1 0 > 13595/0x6b2f3: 515513 5 2 read_nocancel(0x5, "\200\0", 0xFA0) = 128 0 > 13595/0x6b2f3: 515540 25 22 lstat("/Users/aaron/Untitled Folder\0", 0xBFFFF2A8, 0xFA0) = 0 0 > 13595/0x6b2f3: 515548 7 5 getuid(0x15DB0, 0xBFFFF2A8, 0xFA0) = 502 0 > 13595/0x6b2f3: 515549 2 0 getgid(0x15DB0, 0xBFFFF2A8, 0xFA0) = 20 0 > 13595/0x6b2f3: 515551 4 1 lstat("/Users/aaron\0", 0xBFFFF210, 0xFA0) = 0 0 > 13595/0x6b2f3: 515564 14 10 write_nocancel(0x5, "\200\0", 0x74) = 116 0 > 13595/0x6b2f3: 515602 1001061 29 select_nocancel(0x400, 0xBFFFFA94, 0x0) = 0 0
Possibly a duplicate of bug 4645?
Time guesstimation.
$ mkdir A B $ strace mv B A > getegid() = 21025 > getuid() = 4030 > getgid() = 21025 > access("A/B", W_OK) = 0 > rename("B", "A/B") = -1 EXDEV (Invalid cross-device link) > rmdir("A/B") = -1 ENOTEMPTY (Directory not empty)
It looks like the root folder of the export has a different device than the subfolders.
Hopefully fixed in 28638.
Tested using client build 4290 on both 10.6 and 10.9, works as expected.