[MGNLRES-289] Undesired Side-Effects of Watching the File System Created: 24/Oct/16  Updated: 29/Mar/22  Resolved: 14/Mar/22

Status: Closed
Project: Magnolia Resources Module
Component/s: resourceLoaders
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Matthias Müller Assignee: Unassigned
Resolution: Obsolete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Team: Nucleus

 Description   

I've already experienced multiple times, that while magnolia is running and watches a directory (as specified in magnolia.properties file), it causes major conflicts with other tools.

The most problematic issue is, that pulling in GIT (via command line as well as via the gui tool SourceTree) results in files being deleted, if they have merge conflicts. The feedback from the command line:

error: unable to create file path/to/file.yaml (Permission denied)
error: unable to create file another/path/to/file/with/merge/conflict.yaml (Permission denied)

The current workaround is to watch very precisely for GIT errors and recover the deleted files afterwards manually (which is quite easy, as they are version controlled obviously).

Other Tools seem to have conflicts with the way Magnolia watches/locks the file system as well. E.g. The popular editors atom and brackets are frequently unable to delete/move/rename files and folders, while magnolia is running.


Generated at Mon Feb 12 06:49:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.