search

prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.72k stars 1.93k forks source link

Reload from Disk doesn't work if project is saved #2526

Open TickTock- opened 5 years ago

TickTock- commented 5 years ago

Opening a new issue since the one I originally posted was closed:

Reload from disk works as long as I don't save a project. If I just place parts without saving a project I am able to reload an updated STL but I have never been able to load a saved project and re-load from disk to get the updated STL (project comes up with the old STL even though the file has been replaced on the drive - I guess a shadow copy is saved somewhere). Maybe the project points to its own internal copy and forgets the original location so it just reloads its internal copy?

Originally posted by @TickTock- in https://github.com/prusa3d/PrusaSlicer/issues/1890#issuecomment-502528712

jschuh commented 4 years ago

The root problem here is the privacy implication of storing the full source file paths in a destination file that could be broadly shared. I'm very familiar with this particular scenario, and have addressed it in other software with a bit of crypto.

My proposal is to generate a symmetric encryption key at either install or first use, and then store that key within the local settings for this software installation. Whenever you emit a file you first encrypt the full source paths and any other potentially private state you want to store. When you reopen the file within the same installation you will be able to retrieve the state, but other systems will not and can simply discard these fields (as they are not essential to operation).

Depending on how much flexibility you want, you can tweak the protocol a bit (e.g. use asymmetric keys with fingerprints to support multiple keys and sharing). However, I think most people just want their own files to work on their own system during design, so I don't think you really need any of that complexity.

I looked at libslic3r/Format/AMF.cpp, and I could code this up pretty quickly if it would be accepted upstream. I'm just not inclined to do that without that confirmation, because it's not a big need for me, and I already have a pull request pending that I'd like to see landed.

(I see there are quite a few bugs open on this, so hopefully I'm commenting in the right one. If not, please point me in the right direction.)

brettvitaz commented 4 years ago

Super old feature request, I know, but...

The root problem here is the privacy implication of storing the full source file paths

Relative paths are saved in the project, and are perfectly reliable for reloading objects from disk, providing the user does not move object source files.

jschuh commented 4 years ago

Unfortunately, relative paths can still contain sensitive information such as usernames. So, the privacy concern is unresolved if sharing project files with paths (although there is an explicit opt-in to mitigate the risk).

bubnikv commented 3 years ago

Similar to https://github.com/prusa3d/PrusaSlicer/issues/5540