[Bug]: SessionException: Inappropriate ioctl for device on ExFAT file system

[peppy]

What happened?

As reported by a user (ppy/osu#19948), when opening a realm file from an ExFAT disk, an error is thrown.

Weirdly, I cannot reproduce this in an isolated test. I'm not precisely sure how this is happening, but I can reproduce in our game 100%.

Repro steps

• Move a working realm file (excluding .lock / .note files) or create a new realm file on an external drive with ExFAT file system
• Crash

Version

10.15.1

What SDK flavour are you using?

Local Database only

What type of application is this?

Other

Client OS and version

macOS 12.5

Code snippets

https://github.com/ppy/osu/blob/d947a6cb5947c1a3bf1a1d81fd7701266945ffae/osu.Game/Database/RealmAccess.cs#L672-L703

                return Realm.GetInstance(getConfiguration());

...

        private RealmConfiguration getConfiguration(string? filename = null)
        {
            // This is currently the only usage of temporary files at the osu! side.
            // If we use the temporary folder in more situations in the future, this should be moved to a higher level (helper method or OsuGameBase).
            string tempPathLocation = Path.Combine(Path.GetTempPath(), @"lazer");
            if (!Directory.Exists(tempPathLocation))
                Directory.CreateDirectory(tempPathLocation);

            return new RealmConfiguration(storage.GetFullPath(filename ?? Filename, true))
            {
                SchemaVersion = schema_version,
                MigrationCallback = onMigration,
                FallbackPipePath = tempPathLocation,
            };
        }

Of note, removing the FallbackPipePath does not help.

Stacktrace of the exception/crash you're getting

Unhandled exception. Realms.Sync.Exceptions.SessionException: Inappropriate ioctl for device
   at Realms.NativeException.ThrowIfNecessary(Func`2 overrider)
   at Realms.SharedRealmHandle.Open(Configuration configuration, RealmSchema schema, Byte[] encryptionKey)
   at Realms.RealmConfiguration.CreateHandle(RealmSchema schema)
   at Realms.RealmConfigurationBase.CreateRealm()
   at Realms.Realm.GetInstance(RealmConfigurationBase config)


I'm not sure if relevant, but we do not use realm sync in any way.

Relevant log output

No response

[nirinchev]

Transferred to Core as it looks like it would be in your domain of expertise.

[jedelbo]

The FallbackPipePath was introduced in order to be able to put the realm files on ExFat file systems. If it does not help to specify a path where it is possible to create pipes, then it must be something else that is not supported. Unfortunately the exception information does not tell exact what kind of operation that is inappropriate. @peppy would it be possible to get more detailed information?

[peppy]

In our case, just opening the file (via Realm.GetInstance) seems to be enough to trigger it, although as I mentioned, I haven't been able to reproduce the issue in an isolated project, so I'm at a bit of a loss as for why it's happening in our main project..

Do you have any suggestions for how I can better track down the responsible operation?

[fealebenpae]

Try setting FallbackPipePath on your realm configuration, like @jedelbo suggested. The auxiliary files Realm creates next to the database file such as the named pipes used for inter-process notifications likely don't work on ExFAT (we had similar issues with FAT32 in the past). Try setting the property to a folder on an HFS+ or APFS, even Path.GetTempPath() is good enough for a test. If this does fix the issue you just need to pick an application-specific folder for the fallback path (like the application cache folder, for example).

Nevermind, I didn't see it in the snippet.

[peppy]

Thankfully, I think I might have something you can work with. I can reproduce this same issue using realm studio (12.0.0):

fcntl() with F_BARRIERFSYNC failed: Inappropriate ioctl for device

Realm.Studio.2022-08-30.at.06.37.25.mp4

Realm file:
client_24.realm.zip

[jedelbo]

@ironage can you have a look at this? This is not happening on (my) Linux, but a colleague with a Mac confirmed that this is indeed reproducible.

[sync-by-unito]

➤ Finn Andersen commented:

Ok, The message says F_BARRIERFSYNC is not supported on the device. This also implies that the problem relates to the Realm file and not the lock file or a pipe used for emulating robust mutexes.

[peppy]

Thank you for the fix!