https://bugs.documentfoundation.org/show_bug.cgi?id=148478
Justin L <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] |desktop.org | Status|NEW |ASSIGNED --- Comment #15 from Justin L <[email protected]> --- One idea is to wait until just before things are written out (in PowerPointExport::exportDocument when it calls commitStorage()), and then create unique ascii names. However, that looks extremely complex. Things basically just "magically" happen. A key function in the magic is StorageBase::commit(), which eventually calls OStorage_Impl::CommitStreamRelInfo. A similar idea would be (at addRelation time) to query all media files known to the document (however that could be done) and chose a guaranteed-to-be-unique name. I've settled on a third alternative - use an MD5 hash of (the start of) the audio file. This is: -basically non-random -deduplicating (unique to this approach) -highly unlikely to result in a false match The deduplication part is important. Think about the user modifying the document over time. On day 1 he adds a unicode-named audio file and saves as PPTX. The next day he changes that presentation and adds the same unicode-named audio file to a different slide. Without deduplication, this would result in two identical wav files with different made-up-ascii-names. https://gerrit.libreoffice.org/c/core/+/193435 ought to be suitable for real-life, even though there will be multiple ways to manufacture "unintended results" scenarios. -- You are receiving this mail because: You are the assignee for the bug.
