"Error: Function not implemented" on BTRFS

[Byron]

It doesn't seem to be always possible to use the flock crate successfully, and right now this makes the application fail entirely as an exclusive lock can't be acquired.

Since the error code is known, and the locking is just there to prevent multi-window operation which isn't advisable, but also not immediately a problem, one could make the lock optional in this specific case.

Alternatively, we could use the cargo crate and rely on a possibly unstable version of a locking function that probably is more portable. After all, Cargo probably works there.

Discussed in https://github.com/gitbutlerapp/gitbutler/discussions/4851

^{Originally posted by **azzamsa** September 9, 2024} Hi, 👋🏽 I get this error when importing a local repo. I can't import any local repo, I get all similar errors. ``` OS: Fedora Linux 40 (Workstation Edition) x86_64 DE: GNOME 46.4 WM: Mutter (Wayland) ``` ``` 🦄 flatpak list | grep butler GitButler com.gitbutler.gitbutler 0.12.24 stable user ``` ```bash 🦄 flatpak run com.gitbutler.gitbutler ** (git-butler:2): WARNING **: 12:23:58.044: webkit_settings_set_enable_offline_web_application_cache is deprecated and does nothing. 2024-09-09T05:23:58.099414Z INFO crates/gitbutler-tauri/src/main.rs:65: system git executable for fetch/push: "git" 2024-09-09T05:23:58.099500Z INFO crates/gitbutler-tauri/src/main.rs:102: starting app version=0.12.24 name=GitButler 2024-09-09T05:23:58.297572Z INFO list_projects: crates/gitbutler-tauri/src/projects.rs:46: close time.busy=26.5µs time.idle=18.6µs 2024-09-09T05:23:58.306438Z INFO get_user: crates/gitbutler-tauri/src/users.rs:10: close time.busy=17.8µs time.idle=13.5µs 2024-09-09T05:23:58.417188Z INFO get_project: crates/gitbutler-tauri/src/projects.rs:32: close time.busy=3.90ms time.idle=38.7µs id=bd979185-628e-47be-a317-4690096c30a0 no_validation=None 2024-09-09T05:23:58.421456Z ERROR set_project_active:set_project_to_window: crates/gitbutler-tauri/src/window.rs:129: error=Failed to check if lock is taken Caused by: Function not implemented (os error 38) id=bd979185-628e-47be-a317-4690096c30a0 window="main" 2024-09-09T05:23:58.421476Z INFO set_project_active:set_project_to_window: crates/gitbutler-tauri/src/window.rs:129: close time.busy=220µs time.idle=12.9µs id=bd979185-628e-47be-a317-4690096c30a0 window="main" 2024-09-09T05:23:58.421490Z ERROR set_project_active: crates/gitbutler-tauri/src/projects.rs:67: error=Error(Failed to check if lock is taken Caused by: Function not implemented (os error 38)) id=bd979185-628e-47be-a317-4690096c30a0 2024-09-09T05:23:58.421501Z INFO set_project_active: crates/gitbutler-tauri/src/projects.rs:67: close time.busy=3.39ms time.idle=8.36µs id=bd979185-628e-47be-a317-4690096c30a0 2024-09-09T05:23:58.428809Z INFO list_projects: crates/gitbutler-tauri/src/projects.rs:46: close time.busy=45.9µs time.idle=16.9µs 2024-09-09T05:24:01.447957Z INFO get_project: crates/gitbutler-tauri/src/projects.rs:32: close time.busy=3.32ms time.idle=21.8µs id=e6171fce-0396-469c-8371-38809c04b665 no_validation=None 2024-09-09T05:24:01.450663Z ERROR set_project_active:set_project_to_window: crates/gitbutler-tauri/src/window.rs:129: error=Failed to check if lock is taken Caused by: Function not implemented (os error 38) id=e6171fce-0396-469c-8371-38809c04b665 window="main" 2024-09-09T05:24:01.450675Z INFO set_project_active:set_project_to_window: crates/gitbutler-tauri/src/window.rs:129: close time.busy=186µs time.idle=7.23µs id=e6171fce-0396-469c-8371-38809c04b665 window="main" 2024-09-09T05:24:01.450683Z ERROR set_project_active: crates/gitbutler-tauri/src/projects.rs:67: error=Error(Failed to check if lock is taken Caused by: Function not implemented (os error 38)) id=e6171fce-0396-469c-8371-38809c04b665 2024-09-09T05:24:01.450690Z INFO set_project_active: crates/gitbutler-tauri/src/projects.rs:67: close time.busy=2.14ms time.idle=4.82µs id=e6171fce-0396-469c-8371-38809c04b665 ``` 

[Byron]

A question is pending, asking if cargo works on btrfs - if so, we could use the cargo locking implementation for better portability.

CC @ndom91, who even might have btrfs on his machine.

[azzamsa]

@Byron you can throw me a code or snippets for me to run on btrfs.

[Byron]

Thanks a lot for offering to test new versions, and for sharing that cargo works for you which means that its file-locks work.

I investigated this and it seems the best choice here, and what cargo does, is to ignore errors on filesystems that don't support.it.

Once the PR is merged, there is a nightly for you to test.

[ndom91]

Yeah no btrfs here unfortunately. More of a ZFS guy 😅

Side note, I ran into a support request today where someone had their tfstate terraform state file commited and we kept failing in list_virrual_branches due to not being able to get a lock either. And therefore the UI wasn't loading at all. Is this related perhaps?

[Byron]

ZFS is great, too :).

Then I think we'd have to try to get #4900 merged so @azzamsa can try a nightly.

On the side note, list_virrual_branches doesn't get a file-based lock, just an in-memory one which will also block until it's ready. So it should never fail. However, the issue itself seems familiar though - do you have link with more context?

[ndom91]

@Byron haha good ol' virrual branches :joy:

Anyway, it was a support request that came in on the report thing to Intercom, but here's the relevant log lines:

|2024-09-11T01:34:06.569000+0200  INFO handle: crates\gitbutler-watcher\src\handler.rs:57: close time.busy=879s time.idle=14.8µs event=ProjectFileChange(29efdf81-fac4-4860-ab5c-912d15494846, projects\cdktf\terraform.proxy.tfstate)                                   │
│2024-09-11T01:34:06.609000+0200  INFO handle:recalculate_everything:calculate_virtual_branches: crates\gitbutler-watcher\src\handler.rs:93: close time.busy=24.6s time.idle=5.50µs event=ProjectFileChange(29efdf81-fac4-4860-ab5c-912d15494846, projects\cdktf\terrafor│
│2024-09-11T01:34:06.609000+0200  INFO handle:recalculate_everything: crates\gitbutler-watcher\src\handler.rs:129: close time.busy=878s time.idle=3.50µs event=ProjectFileChange(29efdf81-fac4-4860-ab5c-912d15494846, projects\cdktf\terraform.proxy.tfstate) paths=1   │
│2024-09-11T01:34:06.609000+0200 ERROR handle: crates\gitbutler-watcher\src\handler.rs:57: error=failed to list virtual branches                                                                                                                                         │
│                                                                                                                                                                                                                                                                        │
│Caused by:                                                                                                                                                                                                                                                              │
│    0: failed to diff workdir                                                                                                                                                                                                                                           │
│    1: failed to read descriptor: The process cannot access the file because another process has locked a portion of the file.                                                                                                                                          │
│       ; class=Os (2) event=ProjectFileChange(29efdf81-fac4-4860-ab5c-912d15494846, projects\cdktf\terraform.proxy.tfstate)                                                                                                                                            

[Byron]

Right, maybe that issue you referred to was indeed caused by a very early failure due to unreadable files when trying to check for changes, which seems unrelated to this particular issue with unsupported file locks that are acquired once per project.

[Byron]

I am reopening it to wait after @azzamsa could validate the issue is truly resolved. A nightly version with the fix is already available. Thanks again for your help with this.

[ndom91]

I'm not totally caught up here, but I do just want to mention that the Flatpak is a community maintained packaging format. Also Flatpak comes with many sandbox-ing mechanisms that might block access to things such as the project / repository directory, see for example: https://docs.flatpak.org/en/latest/sandbox-permissions.html

[Byron]

Thanks for sharing! This might mean that using a different distribution channel might possibly allow file-locking features to be used as well, which would help preventing the opening of multiple GitButler windows for the same project.

[azzamsa]

@Byron worked like a charm!