Opened 15 years ago

Last modified 11 years ago

#496 closed defect

Journal copies files to datastore before launching them — at Version 11

Reported by: kushal Owned by: kushal
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Sugar Version: Git as of bugdate
Severity: Major Keywords:
Cc: tomeu, kushal, sascha_silbe, sridhar, icarito Distribution/OS:
Bug Status: Unconfirmed

Description (last modified by icarito)

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.

Change History (11)

comment:1 Changed 15 years ago by erikos

  • Bug Status changed from Unconfimed to Assigned
  • Component changed from journal to sugar-datastore
  • Milestone changed from Unspecified by Release Team to 0.86
  • Severity changed from Unspecified to Critical

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

comment:2 Changed 14 years ago by sascha_silbe

  • Component changed from sugar-datastore to journal
  • Distribution/OS Fedora deleted
  • Milestone changed from 0.86 to 0.92
  • Severity changed from Critical to Blocker
  • Version changed from Unspecified to Git as of bugdate

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

comment:3 Changed 14 years ago by bernie

  • Owner changed from tomeu to silbe
  • Status changed from new to assigned

Shouldn't this bug be assigned to silbe?

comment:4 Changed 14 years ago by sascha_silbe

  • Owner changed from silbe to alsroot

alsroot is the Journal maintainer.

comment:5 follow-up: Changed 14 years ago by 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).

comment:6 in reply to: ↑ 5 ; follow-up: Changed 14 years ago by 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.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 14 years ago by kushal

  • Component changed from journal to Jukebox
  • Owner changed from alsroot to kushal
  • Severity changed from Blocker to Major
  • Status changed from assigned to accepted

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.

comment:8 in reply to: ↑ 7 Changed 14 years ago by sascha_silbe

  • Cc kushal sascha_silbe added
  • Component changed from Jukebox to journal

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.

comment:9 Changed 13 years ago by sridhar

  • Cc sridhar added

comment:11 Changed 13 years ago by icarito

  • Cc icarito added
  • Description modified (diff)
  • Summary changed from .m3u files are getting copied rather than creating a new link while playing to Journal copies files to datastore before launching them

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

Note: See TracTickets for help on using tickets.