Design xrefs that should not prevent files being deleted

[ltomuta]

I just uploaded an F3Z file which expanded into 5 designs with two levels of xrefs between them. I then realized that don't need the files and wanted to delete all 5 of them.

After calculating a lot, Fusion told me that it cannot delete the files because there are references that would be broken. This is bogus. All the xrefs are between the files to be deleted, so there would be no file left behind with unresolved references.

I can delete the files if I do it in the correct order, starting with the one referencing the others and then moving down the xref tree until the last file is gone. But it is silly to expect me to do that manually.

The same applies to deleting a folder that contains designs with xrefs. As long as all the xrefs are contained in that folder, the folder can be deleted.

[jeff_strater]

the problem here is Fusion's version management system.  You deleted them from the current version of the referencing design.  However, those references still exist in past versions of the design, and those past versions cannot be deleted.  You can open a past version and use "Save as new version" to make it the current version, and then those XRefs become live again.  So, not "bogus".

If you open the web version of the design:

there is a "trash" icon.  You can move the designs you no longer currently need into the trash bin, and they will no longer show up in the Fusion application, but will not cause problems if an older version is promoted.

[jhackney1972]

Take a look at this Blog Article and Video and see if it helps you delete your files.

[ltomuta]

Nope.

I uploaded one archive file that was expanded into 5 new instances of 5
designs, all v1. File A v1 has dependency on file B v1 which in turn has
dependency on C v1. Same A v1 has dependency on D v1 which in turn depends
on E v1.

There are no other dependencies to any other files, any other versions. At
least not in this universe

I would understand Fusion if I would have asked it to delete E v1. That
would have left D hanging and that in turn would have broken A.

But I asked Fusion at once to delete A, B, C, D and E. All that Fusion has
to do now is build a dependency tree, start removing items from top down and
see that after removing all the requested nodes there will be no dependency
left hanging. Thus deleting the files is safe.

This is further proven by me being able to delete those files one by one,
manually. Would there really be any hidden dependencies I would not be able
to delete any affected file.

Exercise:

Find and assembly with many external components that in turn have external
components/dependencies. Export it all as an F3Z file and then upload it to a new
folder. Now delete the folder. When Fusion refuses to do it, go inside the
folder and delete the assembly file. Then delete all the components that
use other components. Last, delete the remaining files. Then delete the
folder.

Now explain why Fusion did not delete the folder.

[HughesTooling]

You'd think if you select a group of files then delete it would a least delete all the files with no dependences, then you could just select again and delete the next set of files that would free up. Because of the problem deleting assemblies from f3z files I hardly ever try helping people on the form who share FZ3 files because it can be a nightmare deleting the files in the correct order!

The only workaround is move all the files to an empty project then delete the project.

Mark

[ltomuta]

@HughesTooling @jhackney1972 the workaround sounds like a bug. If Fusion really has reasons not to let you delete a file, then that file should be forever kept somewhere (out of sight). Yet they let you delete it with a project, after moving it there!? Makes no sense