When opening and re-opening an old .fzz, it can't find the custom parts anymore

[davidperrenoud]

From andre.knoerig@gmail.com on June 21, 2012 15:40:22

What steps will reproduce the problem? 1. Open an older .fzz, like the 012_EDGY_motor_control.fzz (from fritzing-fab/products)

2. Close it, don't change or save anything.
3. Open it again

It will show errors for not finding any of the custom parts/files.

Original issue: http://code.google.com/p/fritzing/issues/detail?id=2055

[davidperrenoud]

From irasc...@gmail.com on June 21, 2012 15:21:59

the bug goes back at least to 0.7.4, and probably was introduced when we deprecated the .fz file type. Basically, when the file is first opened, the custom parts are added to the internal database and the path where the custom svg files are temporarily stored is cached. When the file is closed, temporary storage is deleted, so the path is now invalid. When the file is reopened, temporary storage is created in a new location but the original cached path still lingers.

Not sure whether the custom parts should be removed from the internal database when the file is closed or just the cached path needs to be updated.

[davidperrenoud]

From irasc...@gmail.com on June 23, 2012 05:14:14

r6088 . custom part is removed from the internal database.

Status: ProbablyFixed

[davidperrenoud]

From googleho...@arcor.de on August 15, 2012 11:57:16

Probably not fixed, assuming that the error message I get comes from the same bug.

When I save my project, close Fritzing and start it again, it opens my project and comes up with the following message:

Error reading file /home/username/.config/Fritzing/partfactory/c5ec17c2e9d4522d3ccbbbf8336637e3/core/generic_sip_9_300mil_hs_1.0mm_0.508mm.fzp: file pcb/generic_sip_9_300mil_hs_1.0mm_0.508mm.svg not found.

Hex code changes each time. Project (so far) only uses parts from core library with appropriate settings. In PCB view, only the label `IC1' for the IC that message obviously refers to (standard IC from core library, set to 9 pin SIP package) appears, no pin holes or outlines. Chip and pin labels (as seen e.g. in schematic view) are intact. In a second attempt for the same project (already using a few more parts) a shrouded male pin header survived closing, but for a molex header only outlines were preserved, pin holes are gone.

[davidperrenoud]

From irasc...@gmail.com on August 15, 2012 14:36:50

If you have a before and/or after version of the sketch file, please attach to the issue tracker so we can take a look.

[davidperrenoud]

From googleho...@arcor.de on August 16, 2012 06:42:33

This is the file (2nd of the two mentioned), opening it still causes the error message mentioned.

Note that in an attempt to make things easier to trace I just threw all the components on a new breadboard (running Fritzing from a newly created Linux user account), and re-opening that (after saving and closing Fritzing) does NOT result in the error message. So it might have been a save thing' that is now fixed, butold' sketches are probably broken forever (well, that sketch is not THAT hard to be done again from scratch...). But see output on stdout/stderr in second attachment for messages shown while throwing components on new breadboard.

Attachment: Verstaerker.fzz fritzing.errlog

[davidperrenoud]

From googleho...@arcor.de on August 16, 2012 07:43:37

... may I add: after opening the newly created sketch on my usual user account (gee, I'm crazy, what exactly made me do that? ;-) ), auto-routing did not work on it (the only two connections on it did not change from thin line' tocopper line'). After removing the directory ~/.config/Fritzing and starting Fritzing again, that worked again. No idea if this is related...

It is probably not clear that my sketch attached above was created using version 0.7.6, so was the deleted directory. But deleting the directory did not remove the error message.

[davidperrenoud]

From irasc...@gmail.com on August 16, 2012 07:48:30

Thanks for attaching the file.

This is a different bug--the part in question is a generated 9-pin SIP, rather than a custom part. The good news is that 'old' sketches with this particular problem are not broken forever, though it may take a patch to the code to get them working again.

I don't yet know the exact mechanism causing the part-regeneration to misfire, nor yet whether the error log or subsequent attempts to autoroute are related.

[davidperrenoud]

From irasc...@gmail.com on August 16, 2012 13:10:40

r6301 restores the missing SIP, however the pins are spaced at 300mil rather than 100mil--I'll have to tend to this later. Unfortunately there's no workaround for the missing part without either building from source or waiting for the next release.

My version of Verstaerker.fzz doesn't have many connections so the autorouting is trivial. Do you have another version of the file that I could test this on?