OneDrive Windows mount: changing file names renders them in capital letters and duplicates

What is the problem you are having with rclone?

I use 2 OneDrive remotes mounted in Windows and both of them face the same problem: when renaming files or creating folders, after hitting ENTER or clicking outside in Windows Explorer, the file is renamed.

Also, files appear duplicated for some reason when they're modified/created, and you need to go back and forth [in Windows explorer] multiple times.

All of this is cosmetic for the mount and changes are commited as they should in the OneDrive interface.

Google Drive and SFTP backends doesn't face this issue.

  • I'm not sure, but I think this issue has been first introduced in v1.60.0.
  • I had this issue through WinFSP 2022, WinFsp 2022.2 and WinFSP 2023.Beta1 (the one I'm currently using). I discard the issue at their side, as I only changed things in my side (upgrade between the different versions) as the last resort step to troubleshoot this issue, and the bug started appearing after an rclone update.
  • By looking at debug logs, the issue seems to be when setting permissions. However, I'd like to keep the possibility of running exe files from my rclone remotes. If there are better ways to overcome this limitation (maybe at the fuse level?), please let me know.

rclone_onedrive

Run the command 'rclone version' and share the full output of the command.

This issue is reproducible in two of my computers (both running Windows 11, but one is Pro and another one is Home), but this is what I get in my main one:

rclone v1.61.1
- os/version: Microsoft Windows 11 Pro 22H2 (64 bit)
- os/kernel: 10.0.22621.963 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.19.4
- go/linking: static
- go/tags: cmount

Which cloud storage system are you using? (eg Google Drive)

OneDrive remotes (I have OneDrive personal and OneDrive for Business), both face the same issue

The command you were trying to run (eg rclone copy /tmp remote:tmp)

mount --file-perms=0777 --volname "OneDrive" --vfs-cache-mode full --cache-dir "E:\Archivos de Programa\rclone\cache" --network-mode OneDrive: B:

The rclone config contents with secrets removed.

[OneDrive]
type = onedrive
drive_type = personal
expose_onenote_files = false
token = REDACTED
drive_id = REDACTED
client_id = REDACTED
client_secret = REDACTED

A log from the command with the -vv flag

This paste has been obtained by running the above command as is (but adding the flag). The followmg has happened:

  • A file has been renamed by adding a 'hello'
  • Renamed it back to the original
  • Create a new 'hello' folder.
  • Remove that folder
  • Create 'hello.txt' file

onedrive_error.log (228.3 KB)

Do you mean if you remove --file-perms=0777 you don't have this problem?

I wouldn't have thought that would do anything under Windows anyway.

Sorry for the delay, I was out for the holidays

That's what I thought by reading the logs seeing the amount of getattr lines in teh debug logs. However, I didn't test without the --file-perms=0777 arguments (stupid me!).

Without that argument, nothing changes and I still face the same problem on OneDrive remotes only. Debug logs also follow the same getattr pattern that is shown in the original logs attached to the thread, so to me they don't seem useful at all (ping me otherwise and I can attach them as well)

And yes, those permissions allow for executables to work as stated in the docs

Hi ferferga,

I can confirm your observations on the latest master: UPPERCASE in Explorer, and sometimes (seemingly) duplicate files, also when doing dir B: from PowerShell. Both disappear after refreshing/repeating one or more times.

You also seem to be right that it that started after an rclone update. I cannot reproduce on v1.56.1. Do you happen to remember which version you updated from?

Next step is patient bisection, but I am currently stuck due to problems building older versions of rclone with the cmount tag on Windows. I get this build error:

PS> git status
HEAD detached at v1.60.0
nothing to commit, working tree clean
PS> go build -tags cmount
# github.com/winfsp/cgofuse/fuse
..\..\..\go\pkg\mod\github.com\winfsp\cgofuse@v1.5.1-0.20220421173602-ce7e5a65cac7\fuse\host_cgo.go:207:10: fatal error: fuse_common.h: No such file or directory
  207 | #include <fuse_common.h>
      |          ^~~~~~~~~~~~~~~
compilation terminated.

Kindly pinging @albertony @ncw for tips to build older versions of rclone with mount support on Windows.

Fixed this, I forgot $env:CGO_ENABLED = 0, so now I can build all versions back to v1.59 - that may be sufficient.

Found the first version with the bug:

rclone v1.59.0
- os/version: Microsoft Windows 11 Pro 22H2 (64 bit)
- os/kernel: 10.0.22621.963 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.18.3
- go/linking: static
- go/tags: cmount

Latest version without the bug:

rclone v1.58.1
- os/version: Microsoft Windows 11 Pro 22H2 (64 bit)
- os/kernel: 10.0.22621.963 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.17.9
- go/linking: dynamic
- go/tags: cmount

Thanks, very good to know!

I can say that the issue is present in this commit:

and that I don't have the knowledge/skills to build the proceeding commit(s) such that mounts are possible:

I then tried to find the corresponding beta release, but can't find out how to match the beta commit hashes with the GitHub commit log.

Although changing the dependencies and buold requirements of Windows of course might play a role in this issue... Why this affects OneDrive only and not other remotes?

I don't see any OneDrive code in those commits, and the fact that everything works great in other remotes but OneDrive it's strange.

Google Drive and (most) SFTP servers are case sensitive (sample.pdf and SAMPLE.PDF are two different files) like in Linux. OneDrive is case insensitive (sample.pdf and SAMPLE.PDF is the same file) like in Windows.

So once I passed the OneDrive polling feature, I started looking for changes affecting casing, mounts, build process etc.

I just checked and it does indeed seem to be a problem with CaseInsensitive backends, it also happens when mounting a local Windows folder. Try something like this:

rclone mount ./testfolder W: --vfs-cache-mode full
1 Like

Thank you very much for the detailed explanation and all your findings Ole.

Not exactly related at all, but probably this can be fixed too?: in OneDrive (and now, by extension, I suppose all the other case insensitive backends as well) it's impossible to change the case of files. For example (those are one of the many combinations possible, as the position of the cases matter. But it serves us for demonstration purposes):

  • saMPLe.pdf → sample.pdf: Impossible

The current workaround is to do: saMPLe.pdf → sample2.pdf → sample.pdf

Thanks Fernando, you are welcome.

Can I persuade you to create an rclone gitHub bug report referring this thread?

This seems to be a more fundamental limitation/bug in rclones handling of case insensitive, yet case preserving backends like Windows, OneDrive, etc. - I doubt it can be solved as part of the above issue and therefore suggest you create a new forum thread.

Here is a PowerShell script illustrating a similar issue with a simple local folder sync on Windows:

PS> rclone touch ./testfolder/saMPLe.pdf
PS> rclone sync ./testfolder/ ./testfolderSync/ -v --stats=0
2023/01/10 09:48:19 INFO  : saMPLe.pdf: Copied (new)
PS> rclone lsl ./testfolderSync/
        0 2023-01-10 09:48:19.118271700 saMPLe.pdf
PS> Rename-Item -Path ./testfolder/saMPLe.pdf -NewName sample.pdf
PS> rclone sync ./testfolder/ ./testfolderSync/ -v --stats=0
2023/01/10 09:48:19 INFO  : There was nothing to transfer
PS> rclone lsl ./testfolderSync/
        0 2023-01-10 09:48:19.118271700 saMPLe.pdf

The beta release versions look like this

rclone v1.62.0-beta.6684.530150b10.vfs2
                                                            ^^^^ branch (if any)
                                         ^^^^^^^^^^ - start of commit hash
                                ^^^^ - commit number (just increments)
          ^^^^^^^ - version of rclone that this will be released in

So you should find the start of commit hash in the changelog.

I don't know if you've tried a git bisect - this is a very powerful way of finding the exact commit things go wrong.

What you need for that is to install a copy mingw and also the fuse headers.

There is a little bat file bin/win-build.bat which I use to set the environment up for go build

@echo off
echo Setting environment variables for mingw+WinFsp compile
set GOPATH=Z:\go
rem set PATH=C:\Program Files\mingw-w64\i686-7.1.0-win32-dwarf-rt_v5-rev0\mingw32\bin;%PATH%
set PATH=C:\Program Files\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0\mingw64\bin;%GOPATH%/bin;%PATH%
set CPATH=C:\Program Files\WinFsp\inc\fuse;C:\Program Files (x86)\WinFsp\inc\fuse

This I would say is the expected behaviour - here rclone knows that saMPLe.pdf and sample.pdf are the same file on a case insensitive file system.

The problem seems to be that this makes it impossible to change the case of files - is that right?

Can this be replicated on the command line or is it a Windows Explorer interaction that is causing the problem?

Exactly, that was the problem. However, I tested and now it seems possible in v1.61.1 and also in v1.58.1 (version outputs above). It must've been sdomething that happened in between those versions (or maybe even a WinFSP bug that it's now solved in the current version I'm using, WinFSP 2023). Both in mount and in CLI with moveto in both versions.

Sorry for bringing into light all the bugs I've been facing these few months ago and that now I'm starting to remember: It was impossible to me to report them before, so I took the holidays as an opportunity. Sorry for all the hassle.

@ncw @Ole Ticket opened at GH in OneDrive Windows mount: changing file names renders them in capital letters and duplicates · Issue #6682 · rclone/rclone · GitHub

Thanks, seems like I just had an unlucky dice where none of commits I searched for had betas.

Perfect, luckily seems like I won't need it this time.

Yes and folders, using both rclone sync and mount.

My script shows how a normal user (non-programmer) may be surprised, that rclone sync doesn't keep file and folder casing up to date on a case insensitive yet case preserving remote.

Things seems a bit different for rclone mount. I cannot change case on folders in the mount (mkdir testFOLDER; ren testFOLDER TESTfolder => Win errormsg) in both Explorer and CMD, but I can change case on files (helloWORLD.txt -> HELLOworld.txt) in both Explorer and CMD. Interestingly the folder change is being silently ignored if I do a change to all uppercase, e.g. mkdir testFOLDER; ren testFOLDER TESTFOLDER.

These oddities may explain why @ferferga first thought there was an issue and now is unable to repeat it, and I therefore think this needs a more thorough retest after fixing the winfsp/cgofuse issue.

Great, thanks!

1 Like

The fix is now available in the latest beta.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.