[MAGNOLIA-5742] JCR Export: creates dangerous file-length Created: 10/Apr/14 Updated: 30/Oct/16 |
|
| Status: | Open |
| Project: | Magnolia |
| Component/s: | build |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Paul Piper | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| 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)
|
| Date of First Response: |
| Description |
|
While working with the module structure we keep running into problems when exporting jcr nodes. The current export functionality relies heavily on the combination of filename and sv:node content to backup and restore information. This, in turn, stores the full jcr path as part of the exported filename, which can lead to various errors with different OS (windows for instance has a 255 character filename-length limit). This is only a mild annoyance whenever you are able to export from a previous subnode (ie, the module as a whole), but turns into a real problem quickly whenever you have to add a node entry in a referenced module (e.g: when adding an available component to a page from another module). Since this is a true limitation, it would be great if the current import/export methods could be overhauled. Since storing the path as part of the xml dom, it would not necessarily seem to be a huge problem to implement. |
| Comments |
| Comment by Michael Dähnert [ 30/Oct/16 ] |
|
This is an often upcoming problem in real life. |