Journal copies files to datastore before launching them

[kushal]

This is especially annoying while installing large activity bundles or even opening large files from removable media in storage constrained systemms like the XO1.

Surely Sugar should be able to open files without copying them to the datastore?

Journal is copying the files these days instead of linking as it used to do. So what is the current way to find from where the actual file comes in?
The usecase is like .m3u files, they mostly contain filepaths in relative way, so if I can not find the actual directory , I can not find the song files mentioned inside it.

[erikos]

Not something we can fix for 0.84 - target is next release. Sadly has impact on #455

[sascha_silbe]

Nothing to be done about it inside the data store (the copying happens in the Journal) and it doesn't cause data loss or similar (=> not Critical).
This is rather unfortunate for the ​Restore activity, BTW. The user needs to have enough disk space for both the backup bundle AND all to-be-restored entries. => Blocker

[bernie]

Shouldn't this bug be assigned to silbe?

[sascha_silbe]

alsroot is the Journal maintainer.

[alsroot]

As we discussed this issue w/ kushal, it could be solved on application level (not sure if it will be useful to keep track the original source, at least can't remember what end-user systems do it). For example we can keep original source in Journal object or so (i.e.. extensive usage of Journal object custom fields).

[alsroot]

Replying to alsroot:

As we discussed this issue w/ kushal, it could be solved on application level (not sure if it will be useful to keep track the original source, at least can't remember what end-user systems do it).

..to keep track on Journal level.

[kushal]

Replying to alsroot:

Replying to alsroot:

As we discussed this issue w/ kushal, it could be solved on application level (not sure if it will be useful to keep track the original source, at least can't remember what end-user systems do it).

..to keep track on Journal level.

Moving the component to jukebox, will try out to fix it in the application level only.

[sascha_silbe]

Replying to kushal:

Moving the component to jukebox, will try out to fix it in the application level only.

As I've mentioned at least Restore is affected by this as well. We should fix it at Sugar level (introducing new API if necessary) rather than requiring activities to work around it. Interfacing with external media on various Sugar versions is already incoherent and bothersome enough.

And even if you work around this on activity level, it will work differently depending on how you invoke the activity. Using the Journal to "resume" the entry will copy it to the Journal whereas starting the activity first and selecting the entry from within the activity will not leave a copy in the Journal. Incoherent UI will confuse the user.

[sridhar]

Downstream bug:
​https://dev.laptop.org.au/issues/784

[icarito]

I do think this is an important bug. I've updated the description and Summary to reflect the importance.

[dnarvaez]

This seems difficult to solve generally given the current sugar API and things will get worst with web activities. Patches welcome, but I don't see this being solved any time soon.