When exporting data to certain formats, eg. Markdown with FrontMatter, there can be some loss of data, with no warnings reported by the UI.
An example of this is that notebook and note names are truncated to 50 characters. Ideally there should be a list of warnings for each item where truncation was necessary to apply. For example, this could be added to a text file report, and feedback is given to the user upon completion of the export, saying that there were some warnings, and pointing to where to find the report.
Another example is a user reported that markdown links to other notes were not replaced correctly, when using the export to Markdown with FrontMatter option. There is specific logic to replace these links in the export process, but if a replacement fails, it should also generate a warning. It was also reported here that emojis and icons can be lost in titles as well.
Hmm, I'm not sure I agree - most export formats are lossy and that's just how it is. Which is why we provide the JEX format, which should export all data and metadata exactly as it is, but the other formats are for convenience and come with drawbacks. You can also export to TXT file which is going to lose a lot of metadata.
What we can do however is improve the export formats to try to lose as little data as possible. Maybe the file titles could be longer (as long as full path is below 255 characters) and maybe we can improve support for emojis
Yeah I'm not saying we need to report on every possible bit of data that can be lost, but the note titles and emojis are the main focus for improvement.
For the note linking, there seems to be some kind of bug which can cause the links to not be replaced properly or ignored, though I wasn't able to reproduce it just by testing it.
Agree we should try to fix this if he can be replicated
I had a look back at the post I was thinking of, and I think the issue with the note links was actually and issue with the import rather than the export. The screenshots show that the note links were correctly substituted to relative paths, and the OP reported that the import did report an error but still did stuff. So I guess the issue is the import process stopped before it reached the logic to convert the relative paths back into links by ids (resource paths were also not working).
The first attempt resulted in a subdirectory that cannot be copied or deleted
This suggests that the import failure was caused by a too long file path. Seeming as the export was successful, it suggests there is a shorter file path constraint for the import vs the export