Cannot update Wow or Overwatch on the btrfs volume with Battle.net client

[SwimmingTiger]

Blizzard Battle.net cannot update World of Warcraft or Overwatch located on the btrfs volume. Every time you click update, it will end with the same error.

The log in AgentNGDP-20201115T084052.log:

[I 2020-11-15 09:35:25.0045] - Update() starts with 0 items
[I 2020-11-15 09:35:25.0046] - Waiting the end condition...
[E 2020-11-15 09:35:25.0173] - failed to open manifest file 'D:/games/overwatch/_retail_/.flavor.info' for writing
[E 2020-11-15 09:35:25.0174] NGDP: Failed to write .flavor.info
[I 2020-11-15 09:35:25.0175] - Cancel updating...

Process Monitor v3.60 recorded a ACCESS DENIED.

But the current user obviously has read and write access to the file. In fact, it can be written normally when opened with any other editor (like notepad.exe).

Process Monitor v3.60 record file:

Logfile.PML.zip

---

WinBtrfs Version: 1.7.4, 1.7.5 Windows version: This problem exists in all Windows 10 versions I have used, from 1903 to 20H2.

---

Notes:

• Not all Blizzard games will encounter update issues, Hearthstone can be updated correctly. I only found this problem with Wow and Overwatch in the Blizzard games I own.

  

• The game installation folder is not damaged. If you double-click the game exe directly, the game can be loaded normally.

  

---

I found a temporary solution to this issue. If I delete the .flavor.info file, Battle.net client will recreate it and the game update can be completed.

Of course, I need to manually delete the file every time when I update.

[maharmstone]

Thanks, I'll try to reproduce. I suspect this is a similar issue to https://github.com/maharmstone/btrfs/issues/291.

[Chaython]

Same as https://github.com/maharmstone/btrfs/issues/325 ? Though my drive is no longer writable at all. Read-Only is set to 0, I hadn't changed anything. Writing was working on Friday.

I did a lot of troubleshooting over the past hours. It seems the drive becomes non-writable after trying to launch Apex Legends in Steam, Steam is trying to write the steamworks common redistributables to the BTRFS partition and it locks up the drive until reboot. - Sorry if this is hijacking your issue, there's just a general write issue that I think if fixed fixes all of the game clients... For steam the temporary solution was to make a symbolic link, for it to download the redists to another drive. Though Steam writing to the drive previously worked...

[maharmstone]

What does btrfs check say on Linux?

[YihaoPeng]

Just in case, I must remind:

Running btrfs check --repair in Linux may cause a btrfs volume that has no major problems to become completely unmountable, and it cannot be repaired to a state where it can be mounted!

I have encountered this problem before. My btrfs volume itself does not seem to have any problems in Linux, and btrfs scrub did not find any errors. But because of the phenomenon with winbtrfs I mentioned in my report above, I thought my volume had a problem, so I try to run btrfs check --repair to repair it.

However, the command exited with a segment fault! Then my btrfs volume became unmountable totally, both in Linux and Windows! I did not find any way to fix it so that it can be mounted again!

I had to use btrfs restore to restore the folders one by one, and found that I lost at least one folder's data.

So just as btrfs check --repair warns: don't use it unless you have no choice! Before using the --repair option, you should back up all data worth keeping. Otherwise you may lose them forever.

Check this page for details:

https://btrfs.wiki.kernel.org/index.php/Btrfsck

Note that while this tool should be able to repair broken filesystems, it is still relatively new code, and has not seen widespread testing on a large range of real-life breakage. It is possible (but highly unlikely in the most recent versions) that it may cause additional damage in the process of repair. btrfs check --repair received significant updates prior to v4.0. You are strongly recommended to use a version after v4.0 when trying to recover a filesystem.

(I have a old version.)

---

Of course, just running btrfs check (without --repair) will not cause btrfs volume damage, because it will not even perform any writes.

But sometimes, you should not trust the result of btrfs check. For my btrfs volume, it always reports several errors. But in fact, if you use btrfs scrub, you will find that the volume is completely fine. And when I use it in the same Linux installation, the volume is completely normal.

---

I think the core of the above problem is that as a user-space application provided by the distribution source, the btrfs-progs package is not updated in time, so it can’t understand the new btrfs features implemented in the kernel, so the data about these new features will be reported as error.

For the same reason, btrfs check --repair will encounter unexpected data structures then crash.

---

If you think there is any problem with your volume, use btrfs scrub start /mount-point to fix it. If the file/folder cannot be accessed due to incorrect Linux permissions/owner, use chmod/chown to fix it. (Need root privileges / sudo.)

It should be noted that a btrfs volume cannot be written in Windows does not mean that it cannot be written in Linux either. The volume may behave normally in Linux. Or you just need root privileges to write to it.

If the volume cannot be written even with root privileges after being mounted in Linux, you can check the kernel log through dmesg (need root privileges / sudo) to see what happened.

[maharmstone]

@YihaoPeng - erm, thanks, but nobody was talking about btrfs check --repair. And it does give a pretty unambiguous warning message if you try to use it.

For my btrfs volume, it always reports several errors. But in fact, if you use btrfs scrub, you will find that the volume is completely fine.

They're measuring different things. Your volume is corrupted.

[YihaoPeng]

They're measuring different things. Your volume is corrupted.

I do not think so. I later found that as long as I create a new volume, copy some files into it, and create some snapshots, btrfs check will report a few of errors.

So I think if the volume is normal in use, it is not damaged. The Linux btrfs driver developers have stated that the btrfs check code is not fully tested, and it is obviously more likely to have problems.

---

Also, the reason why I mention btrfs check --repair is because if btrfs check reported some problems, I will naturally want to use btrfs check --repair to repair it and ignore its warning. Because other file system repair software has similar warnings, I wouldn't expect it to be serious until volume damage and data loss actually occur.

Before btrfs check --repair is truly stable, everyone who uses btrfs check should be reminded of this.

[YihaoPeng]

I found a temporary solution to this issue. If I delete the .flavor.info file, Battle.net client will recreate it and the game update can be completed.

Of course, I need to manually delete the file every time when I update.

[maharmstone]

They're measuring different things. Your volume is corrupted.

I do not think so. I later found that as long as I create a new volume, copy some files into it, and create some snapshots, btrfs check will report a few of errors.

So I think if the volume is normal in use, it is not damaged. The Linux btrfs driver developers have stated that the btrfs check code is not fully tested, and it is obviously more likely to have problems.

I do know what I'm talking about, you know :-) The last version of btrfs check with any false positives that I'm aware of was several years ago. Just because you never encounter any issues doesn't mean that your volume isn't subtly wrong - it might be that an inode you never access is corrupt, for instance.

[YihaoPeng]

The last version of btrfs check with any false positives that I'm aware of was several years ago. Just because you never encounter any issues doesn't mean that your volume isn't subtly wrong - it might be that an inode you never access is corrupt, for instance.

Doesn't btrfs scrub access every inode in the file system?

If it will, why doesn't it find an error?

I think that if the code that actually runs the file system has self-healing capabilities, I should not use external tools (like btrfs check, it is not part of the file system code) to check it. The code that actually runs the file system will be responsible for it, while external tools may not: it may not be compatible with the latest developments in the file system.

[maharmstone]

You're confused about the difference between scrub and check.

Scrubbing verifies data and metadata against checksum errors, and restores it wherever possible. Scrubbing failures are nearly always caused by hard disk problems.

Checking checks that the volume is consistent - e.g. that the st_nlink value of an inode matches the number of hard links, that each directory entry is index both by number and by hash, that the extent tree matches what the inodes point to. Checking failures are only ever caused by driver problems, or possibly in rare cases by faulty RAM.

I've just noticed that you have the same profile pic as @SwimmingTiger, so I'm assuming you have two accounts. If you want me to look into your issue, please post the output of btrfs check as requested.

[YihaoPeng]

I've just noticed that you have the same profile pic as @SwimmingTiger, so I'm assuming you have two accounts. If you want me to look into your issue, please post the output of btrfs check as requested.

Thank you. Both are my account.

But I think I should really submit an issue to the Linux btrfs utility.

I really don't think there is a problem with my volume because it looks so normal. And even if I re-created a volume, a similar error was reported quickly (Only in Linux, so it has nothing to do with winbtrfs. Run 5.9 kernel).

[maharmstone]

Closing as user refused to give information requested.

[YihaoPeng]

The issue has been closed, but as a supplement, I don’t think the result of btrfs check is related to the issue.

Because actually, when my volume was completely damaged by btrfs check --repair, I reformatted the volume and copied the game files again in Linux. But the result is that the same problem still exists on Windows.

So, this should be a issue about how to deal with Windows file permissions (ACL) when opening a file multiple times, not a issue about volume damage.

And, when I run the Battle.net client with Wine on Linux with the same Wow and Overwatch installation folder, everything is fine. This again proves that the volume is not damaged.

The reason why I mentioned the results of my btrfs check is to prevent others from damaging their volumes by running btrfs check --repair. Unfortunately, the subsequent discussion completely deviated from the direction.

[maharmstone]

This must be the oddest bug report I've ever received...