PowerPoint 2013: Images in presentation disappear - and are replaced with 'The image part with relationship ID rId2 was not found in the file'

Are you telling us that all current MS Office applications have been built around a core that dates back 24 years, and there has been no complete rewrite? This is horrible....

I don't think this conclusion makes sense. Otherwise why would the problem not exist when saving in Powerpoint 2003 format?

This seems a little strange to me, since I am not aware of problems with ODF, which is saved in a similar manner (zipped markup and binary files). In fact, most files can just be pushed into Dropbox without any issues. So I'm thinking that HOW the files are being saved might be the solution. A temporary workaround for MS might even be to deactivate this restoring function (which should get rid of the necessity of a temporary file or locks on files).

Yes it does seem that how the files are saved is the problem. I suspect that the file saving routing goes through multiple saving steps rather than just one straight Open -> Stream the bytes to the file -> Flush and Close, and there is a race condition somewhere which is conflicting with other programs that might be monitoring file changes. So if powerpoint is going through 2 steps for example, there is a small chance that after step 1, in that split second Dropbox or whichever cloud sync solution one uses notices that there was a change to the file, and opens the file to sync it. In the mean time powerpoint tries to open it again for step 2, maybe to save the images or something, and fails, which ends up corrupting the ppt file due to the missing image data. I don't know, its my interpretation from the behaviour I am observing. The only cloud synching software I have is Dropbox, clicking 'Pause synching' seems to reduce the chances of the problem happening.

What is most disappointing in this is that this bug has been around for a year now, and no fix has been issued. I am so paranoid about this that I am saving a new ppt file every couple of slides, ending up with 40 versions or so, just to make sure that if it gets messed up I can at least go back to a previous version. Nightmare!

The thing is, once I began to suspect it might be a Dropbox issue, I started doing all my file saving locally and just copying the file out to Dropbox when I needed to.

I still had the problem. It didn't go away when I started saving it locally.

It went away when I uninstalled Genie Pro backup software.

MM

Another point to remember is that every Office application is at it's very core a teeny-tiny (it used to be installed from a couple of 180KB(!) "floppy disks!) program written for "DOS" (ie "Single-computer" (NO NETWORKING!) ) back in the 1980's! 

Are you telling us that all current MS Office applications have been built around a core that dates back 24 years, and there has been no complete rewrite? This is horrible....

Do you have any sources for this?

I really wonder the reasons for this decision...

Yes, that is what I am saying.

I don't have any "official" documentation, but all you have to do is look at the "legacy" functionality that is still there, for example field codes and the "Highlighter". 

Why does the highlighter feature still only offer 15 color options, the "VGA 15"? In any rational world it would offer the same color options dialog as any other color feature.  (sorry, that is a pet peeve of mine).

Why is the bullets and numbering feature so "quirky"?

Yes, there have been a few "re-writes", in part, the latest one in Office 2013. But they have maintained a great deal of "backward compatibility". There have been "re-writes" every time the "bitness" changed, from 8-bit to 16 to 32 and finally 64-bit.  There were also re-writes when Office migrated from DOS to Windows and another when they went to Windows NT.

Old code can be buried inside of "wrapper" code that translates between the new and old code.

How much, if any "original" code is still there, I don't know. If you want to look at source code, normally I would say "good luck". But in a stroke of co-incidence, I read this article yesterday. MS has just released its source code for Win Word 1.0. You could look at that code for the highlighter feature to see if there is anything identifiably "ancient" about it. Since it still looks the same in 2013, odd are good it would still be using that at least 15 year old code.

http://www.theregister.co.uk/2014/03/25/microsoft\_releases\_operating\_system\_source\_code/

Why keep using "old code"? 

      Why not?

It has been thoroughly tested and debugged. It has been proven to work.  In other words, "if it ain't broke, don't fix it".  Actually, it is a fundamental concept in software maintenance. If you touch the code, you have to retest it completely because you could have introduced a new error. That adds time and EXPENSE to your development process. So it is better not to make any changes unless you absolutely have to.

Actually, that phrase is a mis-statement. Most managers hide behind it. But they ignore the second half of the phrase, the one that almost no one acknowledges.  The whole phrase should be ...

  "if it ain't broke, don't fix it ...

but first, you have to define what is 'broke' and what is 'ain't broke' "

Just because a program runs to completion and creates the correct answer does not mean it is "ain't broke".  We had a process that ran in 6 hours.  After it was 'improved', it ran 26 hours.  That was a bit of a problem since it had to be run every night.  This was a case where it was easy to say that although the correct output was created, the process was still "broke".  Usually, the dividing line between broke and ain't is much more subtle and it is much harder (aka impossible) to convince management that something that works really is broke and it needs to be fixed.

JBX1 is probably correct that the "old code" is not directly part of this Red-X problem. That problem is specific to the "new" 2007 x-file format as it is being used in PPT 2013.

Hi

After many hours of tinkering, it appears that a backup program called SquirrelSave may be the culprit in my case.  It is one of those programs that monitors and upload files as they change.

It may be a coincidence and I'll keep trying to ensure that this is correct.  It does appear that even pausing the backup process does not alleviate the problem - the program needs to be closed completely.

This raises an issue which may underly the problem:  Since pptx files are zipped file repositories, it is possible that the component files are not all locked by Powerpoint when the presentation is opened.  The backup software cannot detect that the files are 'in use' when saving files, leading to a sharing violation.  This might explain why old images (which may not be locked when the pptx is opened) disappear, but newly-inserted images are locked so they are preserved.

Just a thought...

Can anybody shed some light on where the pptx files are opened?  Is it a temporary directory?

-Ronnie