Adding comment on system instability caused by a privileged cp.

[TZubiri]

You guys are not receiving issues on this repository, and I'm not going to open an account at yet another issue tracker and possibly have my issue closed, thank you very much.

As you might tell, this is a very important issue, I hope you don't have many more important than this. I'm available to answer any questions or provide debugging material.

I await your response, thank you.

Thanks for helping us make a better snapd!
Have you signed the license agreement and read the contribution guide?

[mvo5]

Thanks for this problem report. We are working on a fix to make snapd more diskspace aware so it is more mindful in situations like the one you describe there. The remark about the performance is important too, we can explore if using ionice would help here. The diskspace awareness feature will most likely start in the next couple of weeks.

[TZubiri]

Hello, thanks for responding to my pull request. Yesterday my started malfunctioning, so I rebooted, and the system couldn't boot again.
The first suspect was lack of disk space, triggered by this bug.
I confirmed this by booting from another OS, mounting my drive and going to the biggest folders Snap tries to copy with this command. Upon inspecting its contents I find that there are 2 folders "/home/tomas/snap/obs-studio/1068" and 1071
1071 weighs 5.3G and 1068 591M, the small folder has 8 files that already exist in the big folder
They all have the same file size so I can't guarantee that this was an interrupted copy, but maybe the filesize is determined at the start of cp and is reserved even if interrupted.
At any rate, let's fix this.
i'll start with a couple of questions
1)why does this cp need to happen at all?
2) could it be a mv instead?
3) is this something triggered entirely by snap or does the package itself have partial responsibility?

Regards, Tomás

[anonymouse64]

Upon inspecting its contents I find that there are 2 folders "/home/tomas/snap/obs-studio/1068" and 1071
1071 weighs 5.3G and 1068 591M

This is because these directories are the $SNAP_USER_DATA directories for your user for the obs-studio snap. These directories are per-revision such that each revision of the obs-studio snap has an independent directory to allow for rollbacks. For example if you had another refresh to obs-studio to bring you to revision 1100, all of the files in 1071 would be copied to the 1100 directory such that if you then started to use revision 1100, to the application it would look like it had all the same files as revision 1071 did before the update, but if you found problems with 1100, you could revert back to 1071, and any changes that 1100 made would not affect the 1071 revision of obs-studio.

It sounds however like the data you have in this directory is rather large and perhaps it is more important to optimize for disk space for you rather than to have robustness and be able to rollback. There is another directory that is shared between revisions and does not get copied upon updates, $SNAP_USER_COMMON that may be a better place for some of those files to live. That directory will be something like /home/tomas/snap/obs-studio/common. I don't know what the files are or if you are able to just move the files around without breaking obs-studio, so it is probably better to reach out to the developers of the obs-studio snap to discuss this further. They have a GitHub at https://github.com/snapcrafters/obs-studio/issues.

Hopefully this helps answer your questions. I am going to close this PR for now, but feel free to continue to comment or ask questions here, but note that we do prefer discussion of such issues take place either on our bug track bugs.launchpad.net or on our discourse instance forum.snapcraft.io. Thanks