ATF safety

[Martin Aumueller]

If such a data corruption as some ATF users experienced happened to me, I'd be 
pissed. If turning this feature on would have been recommended by the program 
that caused the corruption, then doubly so. And even more so, if its 
developers continuously insist on it being safe despite I having proof of the 
opposite.

Thus I suggest that we:
- leave ATF disabled by default (probably forever)
- remove any ATF recommendation in Amarok's config dialog
- stop insisting on its safety
- and please try to make the code easier to understand more safe
  * we should properly lock files that any Amarok process writes to (imagine a 
writable collection shared by several users - this is not only ATF related)
  * do not make the behaviour of MetaBundle dependent on a process name (this 
is not very transparent to the caller, and some day, the process names might 
change and ATF will stop working)
  * avoid code that needs triple WARNINGs in the comments (some setUniqueId 
that we have right now) - the code should be easily understandable by all 
developers
  * limit the locations where meta data writes are triggered to as few places 
as possible and make it more clear when this happens
  * make the ATF related parts of the MetaBundle API behave just as the rest 
of MetaBundle - Amarok developers are already familiar with this pattern:
    + a setUniqueId(QString) call that sets the unique id *only in memory*
    + a uniqueId() call for querying the unique id
    + write the unique id together with the other tags in MetaBundle::save()
    + perhaps provide a saveUniqueId() as an optimization for only writing the 
unique id to the file
  * with this changed API, the collection scanner could just call 
bundle->setUniqueId(somerandomid); bundle->saveUniqueId() - no need for 
special casing MetaBundle for processes having a certain name

On Thu August 17 2006 07:27, Jeff Mitchell wrote:
> > and despite Jeff's insistence on its
> > safety,
>
> It *is* safe.  It just wasn't *process-safe*  :-D  The code worked exactly
> as planned, I just didn't plan to have it working twice at the same time. 
> Go figure...  :-)
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok