#Local function throws EACCES error when automatically rebuilding.

26 messages · Page 1 of 1 (latest)

glass sage
#

I am developing an Appwrite function locally. Up until now, the process has been as smooth as butter: I edit my files, save them, and this triggers a rebuild of the local function deployment. All as expected.

However, as of today, I randomly receive the error below. When it happens, the local function server stops, and I have to Ctrl-C the process and rerun appwrite run functions --port 3001 --function-id="api"

The error does not happen all the time and sometimes I get a whole 5 minutes or so of editing and switching contexts between Insomnia and VS Code before it happens.

What's more curious is that I don't even have to edit and save anything. Sometimes it's enough to click out into Insomnia or Postman, trigger the function with a few REST calls and then when I click back into VS Code, some or other "change" is detected and everything rebuilds, throwing the error.

The only difference in my environment is that I recently activated CoPilot in VS Code. Is anyone else developing Appwrite functions locally in conjunction with VS Code and Copilot? Anyone else have this problem?

ℹ Info: Cancelling build ...
ℹ Info: Rebuilding the function due to file changes ...
Error: EACCES: permission denied, copyfile '/Development/limetrack/cli/functions/limetrack_api/.git/modules/packages/lt_collections_appwrite/objects/pack/pack-0550a30ac4f7fbdeef0c1a57750334087627035c.idx' -> '/Development/limetrack/cli/functions/limetrack_api/.appwrite/tmp-build/.git/modules/packages/lt_collections_appwrite/objects/pack/pack-0550a30ac4f7fbdeef0c1a57750334087627035c.idx'
    at Object.copyFileSync (node:fs:3087:11)
    at dockerBuild (/opt/homebrew/Cellar/appwrite/6.2.3/libexec/lib/node_modules/appwrite-cli/lib/emulation/docker.js:76:12)
    at EventEmitter.<anonymous> (/opt/homebrew/Cellar/appwrite/6.2.3/libexec/lib/node_modules/appwrite-cli/lib/commands/run.js:219:23) {
  errno: -13,
  code: 'EACCES',
  syscall: 'copyfile',
  path: '/Development/limetrack/cli/functions/limetrack_api/.git/modules/packages/lt_collections_appwrite/objects/pack/pack-0550a30ac4f7fbdeef0c1a57750334087627035c.idx',
  dest: '/Development/limetrack/cli/functions/limetrack_api/.appwrite/tmp-build/.git/modules/packages/lt_collections_appwrite/objects/pack/pack-0550a30ac4f7fbdeef0c1a57750334087627035c.idx'
}
ebon bough
glass sage
#

So the .appwrite/tmp-build does not exist until an auto rebuild happens. And when everything stops after throwing the EACCES error, the folder is there and the contents match the source.

#

There does not appear to be any restrictions on the read. So the only thing I can think of is perhaps the destination is locked when the copy happens - perhaps because it's being triggered multiple times in quick succession?

#

The "Cancelling build..." kind of pushes me toward the idea that it's trying to rebuild more than once in rapid succession.

#

Perhaps the rebuild process needs a small delay after cancelling to allow time for file locks etc. to be released by the OS.

I would love it if one of the Appwrite Function devs could weigh in.

ebon bough
glass sage
glass sage
#

@slate lagoon @grizzled wedge Any thoughts on this? It's really hampering development having to restart the local function every few seconds.

macOS Sequoia 15.4.1
Appwrite CLI: 6.2.3
Docker Desktop: 4.41.2 (191736)
Docker Engine: 28.1.1
VSCode: 1.100.0 (with GitHub Copilot extension 1.317.0)
Appwrite Function: Dart 3.5

#

I have disabled Copilot to rule out the most recent change in my development environment but the issue is still happens. It seems mostly triggered when I return focus to VS Code after using another app (like Insomnia or the browser to check my Appwrite collections).

#

It seems clear that when switching back into VS Code, a new build of the function is triggered, then cancelled and then restarted - all within micro-/milliseconds of each other and this seems to cause a permissions issue (probably because of file locking).

📎 message.txt
#

Is there any way to "narrow" down which files Appwrite is monitoring? I assume that it's monitoring the entire function's folder for any changes... does this include hidden files and folders (like .appwrite, .dart_tool, .git, .github, .gitignore and .vscode)?

slate lagoon
#

maybe vscode is doing a git fetch or something on focus

glass sage
#

Thanks for the reply @slate lagoon . As the code you referenced is core Appwrite code, I'm assuming that you mean I should add .git to .gitignore so that when Appwrite parses the file it knows to ignore the directory?

#

This is not advisable:

#

Adding the .git folder itself to .gitignore is not recommended and can be risky. The .git directory is essential for Git to function, as it contains all the repository’s data, history, and configuration. Ignoring it with .gitignore has no effect on an existing repository because .git is already untracked by Git by default, and Git does not allow you to add or commit the .git directory itself.
Risks and Issues:
• If you somehow remove or corrupt the .git directory, your repository will lose all version history and configuration, effectively breaking Git functionality for that project.
• Exposing the .git folder (for example, on a web server) is a major security risk, as it can allow attackers to access your entire repository, including sensitive information.
• .gitignore is designed to prevent new files or folders from being tracked, not to protect or manage core Git directories.

Conclusion:
You cannot and should not add the .git folder to .gitignore. There is no benefit, and it does not provide additional safety-on the contrary, mishandling the .git folder can break your repository or expose it to security risks.

#

I would imagine that the following should be added to the Appwrite code:

ignorer.add('.dart_tool');
ignorer.add('.git');
ignorer.add('.github'); ignorer.add('.vscode');

These are all utility folders and are not related to the function. Ergo, changes here should not cause a rebuild.

slate lagoon
glass sage
glass sage
#

After a quick test, this appears to have resolved the issue and restored the original behaviour.

#

Following your suggestion, I also looked at VS Code's output logs and can see the following every time that I switch back into VS Code from another app. So your initial assumption was indeed correct.

2025-05-14 02:26:43.455 [info] > git ls-files --stage -- lib/main.dart [11ms]
2025-05-14 02:26:43.462 [info] > git fetch [1286ms]
2025-05-14 02:26:43.470 [info] > git cat-file -s c9123b1e4cec5f66ef3a6d0f855cbcb73e1a2709 [14ms]
2025-05-14 02:26:43.476 [info] > git config --get commit.template [13ms]
2025-05-14 02:26:43.477 [info] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) --ignore-case refs/heads/main refs/remotes/main [13ms]
2025-05-14 02:26:43.489 [info] > git show --textconv :lib/main.dart [13ms]
2025-05-14 02:26:43.490 [info] > git for-each-ref --sort -committerdate --format %(refname)%00%(objectname)%00%(*objectname) [11ms]
2025-05-14 02:26:43.492 [info] > git status -z -uall [14ms]
2025-05-14 02:26:44.572 [info] > git ls-files --stage -- lib/main.dart [17ms]
2025-05-14 02:26:44.594 [info] > git cat-file -s c9123b1e4cec5f66ef3a6d0f855cbcb73e1a2709 [20ms]
2025-05-14 02:26:44.608 [info] > git show --textconv :lib/main.dart [12ms]
#

It does mean that I (and anyone else using VS Code with the git extension), is going to have to add an ignore section to their function. Can this be documented in the Develop Appwrite Functions > Develop Locally docs?

#

Wouldn't a better approach be for Appwrite to iterate the folders in the function's folder and automatically add anything starting with '.' to the ignorer?