rename syscall fails with EPERM

[nkakuev]

The modernize-loop-convert-extra test from Clang tools test suite fails, producing the following output:

error: unable to rename temporary '/mnt/c/Users/Nikita/Documents/Git/llvm/build/tools/clang/tools/extra/test/clang-tidy/Output/modernize-loop-convert-extra.cpp.tmp.cpp-e98e2900' to output file '/mnt/c/Users/Nikita/Documents/Git/llvm/build/tools/clang/tools/extra/test/clang-tidy/Output/modernize-loop-convert-extra.cpp.tmp.cpp': 'Operation not permitted'

Upon closer inspection, it turns out that rename syscall fails with EPERM:

rename("/mnt/c/Users/Nikita/Documents/Git/llvm/build/tools/clang/tools/extra/test/clang-tidy/Output/modernize-loop-convert-extra.cpp.tmp.cpp-9fcd310f", "/mnt/c/Users/Nikita/Documents/Git/llvm/build/tools/clang/tools/extra/test/clang-tidy/Output/modernize-loop-convert-extra.cpp.tmp.cpp") = -1 EPERM (Operation not permitted)

All files belong to the current user, the S_ISVTX permission bit doesn't seem to be set, running the same command as root doesn't help. All antivirus software is off. Full strace output is available here - https://gist.github.com/anonymous/136518348cf7e3b8f347f8d73301372c

The problem is not reproducible on regular Linux (Clang tools builds are passing), but 100% reproducible on WSL.

Repro steps:

1. Checkout LLVM, Clang, and extra tools as described here - http://clang.llvm.org/get_started.html
2. Build clang-tidy - make check-clang-tools

The failing command will look something like this:

• clang-tidy /mnt/c/Users/Nikita/Documents/Git/llvm/build/tools/clang/tools/extra/test/clang-tidy/Output/modernize-loop-convert-extra.cpp.tmp.cpp -fix --checks='-*,modernize-loop-convert' -- -std=c++11 -I /mnt/c/Users/Nikita/Documents/Git/llvm/llvm/tools/clang/tools/extra/test/clang-tidy/Inputs/modernize-loop-convert

Required packages:
binutils, subversion, cmake, make, gcc, python, zlib

Microsoft Windows [Version 10.0.14393]

[pcc]

Here's a smaller reproducer for what Clang is doing. Note that Clang isn't issuing the munmap system call that I've commented out. If I uncomment it, the system call succeeds.

#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main() {
  int fd = open("b", O_RDONLY);
  void *p = mmap(0, 3, PROT_READ, MAP_PRIVATE, fd, 0);
  //munmap(p, 3);
  close(fd);
  rename("a", "b");
}

To reproduce (from a Windows file system):

1. Put the above in rename.c
2. make rename
3. touch a
4. echo foo > b
5. ./rename

This seems like a problem that we could work around in Clang by munmaping the destination file before we issue the rename. Although it would be nice if the rename could somehow succeed, I have a feeling that this is WAI due to Windows filesystem semantics.

[benhillis]

@pcc - can you confirm what build you're trying this on? I'm trying this on 14975 and your above example is working for me (without the munmap call).

Strace output:

open("b", O_RDONLY)                     = 3
mmap(NULL, 3, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc64956d000
close(3)                                = 0
rename("a", "b")                        = 0
exit_group(0)                           = ?
+++ exited with 0 +++

[pcc]

This was also on 14393. If this is succeeding on a Windows filesystem (i.e. /mnt/X) I suppose this is another case where the bug is already fixed.

[benhillis]

@pcc - sorry I missed the piece about this having to be in a DrvFs mount. In that case you're right, Windows file system semantics are different than Linux and files cannot be renamed while they are in use.

[PetterS]

Does anyone know whether this is planned to be fixed in Clang? clang-tidy 4.0 does not run correctly in WSL Creator’s edition for this reason.

[pcc]

@PetterS please file a bug at bugs.llvm.org if you would like to see this fixed in Clang.

[therealkenc]

This one (as narrowly defined by pcc's test case above) was addressed in WSL1 along the way. Possibly around the time of #966 work, or maybe it was some of the mmap improvements. Better on WSL2 as well natch.