Perforce and Multi-User asset corruption

I have a really weird and unacceptable problem when using Perforce and the new multi-user editing feature.
It only seems to happen when I’m in a session with a friend and we’re working together. I haven’t noticed it occuring when using source-control alone or being alone in a session.

Basically, the files get corrupted on the server. We first noticed it when my friend wanted to get the latest revision to do some work, and he just couldn’t open the project. No crash, nothing, even the logs were pretty humble. We finally found out it was due to one of the assets, so we replaced it with a working copy, but of course it kept happening, so we decided to just make a new server from scratch. And it happened again, this time on a level asset.
Right after I save everything (persist session changes and submit in perforce) I immediately get the latest revision on my “test” workspace to see if something got corrupted. Unfortunately, it does more than half of the time and we have to go back and try to submit again.
As I said, it happens pretty randomly and I don’t know what causes it. I wasn’t able to reproduce it in a one person session and using source control by itself, because of course it’s bound to happen when we’re actually working.
I guess it might be related to the beta version, but I hope it can be fixed because it drives me into madness each time it happens. And it happens most of the time we submit to source-control.

If you know anything about this problem/bug, then please let me know, because it’s seriously driving us crazy and we haven’t found anything that would be even remotely related to it.

Btw, engine version: 4.23.0 (not preview) but there is no such option here.

**UPDATE: ** I’ve noticed that the corrupted files have one thing in common. To be exact there is a weird pattern inside the file. I used VBinDiff to compare good files with bad ones and I noticed there is always an additional 0D byte right before every 0A byte. I think this might be a problem with Perforce because since 0A is line feed (in ASCII) and 0D is carriage return, it seems like it just inserts it right before the line break, so it assumes it’s like a text file?
I honestly don’t know what to think about it.
0D before 0A image

Bump, this is happening in 4.26 too

If anyone is still having this issue
You just have to change the file type in Perforce from text to binary.
Turns out that mysterious “0D” byte is a CR (carriage return) that Windows has before every LF (line feed aka new line) character.
I was dumb, sorry, we all learn new things everyday :slight_smile: