[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: |
| 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. |