Before you move folders please be advised and warned there is active heavy machinery (active directories) with moving parts you need to watch carefully for before taking any action.

Risk of www.Snapcraft.io blindsiding users in the middle of a transfer is a catastrophic failure of data loss, from running multiple sync processes for the same data, which if it breaks MySQL (all the time in Cloud data centers), will definitely break a user too.

I commented Move snap packages to another location/directory "Riskwise, does it matter if Snapcraft it [is] active (How to stop snapd from auto-updating?) during Rsync behaviors? Snap does not give predictable timing, and can push random updates during this parallel (r)sync, leading to catastrophic data loss in that important edge case? I edited the script at askubuntu.com/review/suggested-edits/1167854 with sudo systemctl mask/stop/disable snapd.service before, and sudo systemctl unmask/start/reenable snapd.service after, in an abundance of caution."

Originally from my edits at https://askubuntu.com/review/suggested-edits/1167854 & https://askubuntu.com/review/suggested-edits/1168074, which the first was predictably not approved because I said "Snapcraftiness" to describe the terroristic craftiness of the auto-update mechanism. (We went from the deservedly-loved apt-get to snap/snapcraft and it could have been called "snapt" instead to pay homage, somebody thought the ever-so-witty "snapcraft" was a better descriptor so I think my wording Snapcraftiness is accurately best fitting and appropriate coding.

I've used a computer for 25 years and the first year I ever had an program problem was from installing Snapcraft.io and finding it upgrading software which did not lead to any improvement and caused actual degredation in service that the service provider denies in face of loads of user evidence. One day I found that was deeper than a bug, and nearly a hack, fully not standardized officially, describable as an inherent risk to normal/regular users.

These kinds of risks are known to corrupt data, corrupt hard drives, even corrupt entire data center servers when multiple data operations are committed to the same data points, it becomes a physical issue where the is overlapping activity which can ruin physical data storage, if not just cause software data corruption issues, sometimes known as "race conditions" (https://en.wikipedia.org/wiki/Race_condition, https://simple.wikipedia.org/wiki/Race_condition, https://stackoverflow.com/questions/34510/what-is-a-race-condition) in the programmer community similarly, if not watched carefully.

I speak from personal experience having these issues occur, and having read others experiences dealing with the aftermath of the ignorant way some software/repositories is/are blatently run not keeping these risked users in mind.

Before you move folders please be advised and warned there is active heavy machinery (active directories) with moving parts you need to watch carefully for before taking any action.

Risk of www.Snapcraft.io blindsiding users in the middle of a transfer is a catastrophic failure of data loss, from running multiple sync processes for the same data, which if it breaks MySQL (all the time in Cloud data centers), will definitely break a user too.

I commented Move snap packages to another location/directory "Riskwise, does it matter if Snapcraft it [is] active (How to stop snapd from auto-updating?) during Rsync behaviors? Snap does not give predictable timing, and can push random updates during this parallel (r)sync, leading to catastrophic data loss in that important edge case? I edited the script at askubuntu.com/review/suggested-edits/1167854 with sudo systemctl mask/stop/disable snapd.service before, and sudo systemctl unmask/start/reenable snapd.service after, in an abundance of caution."

Originally from my edits at https://askubuntu.com/review/suggested-edits/1167854 & https://askubuntu.com/review/suggested-edits/1168074, which the first was predictably not approved because I said "Snapcraftiness" to describe the terroristic craftiness and corruption of the auto-update mechanism. (We went from the deservedly-loved apt-get to snap/snapcraft and it could have been called "snapt" instead to pay homage, somebody thought the ever-so-witty "snapcraft" was a better descriptor so I think my wording Snapcraftiness is accurately best fitting and appropriate coding.

I've used a computer for 25 years and the first year I ever had an program problem was from installing Snapcraft.io and finding it upgrading software which did not lead to any improvement and caused actual degredation in service that the service provider denies in face of loads of user evidence. One day I found that was deeper than a bug, and nearly a hack, fully not standardized officially, describable as an inherent risk to normal/regular users.

These kinds of risks are known to corrupt data, corrupt hard drives, even corrupt entire data center servers when multiple data operations are committed to the same data points, it becomes a physical issue where there is overlapping activity which can ruin physical data storage, if not just cause software data corruption issues, sometimes known as "race conditions" (https://en.wikipedia.org/wiki/Race_condition, https://simple.wikipedia.org/wiki/Race_condition, https://stackoverflow.com/questions/34510/what-is-a-race-condition) in the programmer community similarly, if not watched carefully.

I speak from personal experience having these issues occur, and having read others experiences dealing with the aftermath of the ignorant way some software/repositories is/are blatently run not keeping these risked users in mind.

Before you move folders please be advised and warned there is active heavy machinery (active directories) with moving parts you need to watch carefully for before taking any action.

Risk of www.Snapcraft.io blindsiding users in the middle of a transfer is a catastrophic failure of data loss, from running multiple sync processes for the same data, which if it breaks MySQL (all the time in Cloud data centers), will definitely break a user too.

I commented Move snap packages to another location/directory "Riskwise, does it matter if Snapcraft it active (askubuntu.com/questions/1045542/…) during Rsync behaviors? Snap does not give predictable timing, and can push random updates during this parallel (r)sync, leading to catastrophic data loss in that important edge case? I edited the script at askubuntu.com/review/suggested-edits/1167854 with sudo systemctl mask/stop/disable snapd.service before, and sudo systemctl unmask/start/reenable snapd.service after, in an abundance of caution."

Originally from my edit at https://askubuntu.com/review/suggested-edits/1167854 & https://askubuntu.com/review/suggested-edits/1168074, which the first was not approved because I said "Snapcraftiness" to describe the terroristic craftiness of the auto-update mechanism. (We went from apt-get to snap and it could have been called "snapt" instead, somebody thought snapcraft was a better descriptor so I think my coding is accurately best fitting.

I've used a computer for 25 years and the first year I ever had an program problem was from installing Snapcraft.io and finding it upgrading software which did not lead to any improvement and caused actual degredation in service that the service provider denies in face of loads of user evidence. One day I found that was deeper than a bug, and nearly a hack, fully not standardized officially, describable as an inherent risk to normal/regular users.

These kinds of risks are known to corrupt data, corrupt hard drives, even corrupt entire data center servers when multiple data operations are committed to the same data points, it becomes a physical issue where the is overlapping activity which can ruin physical data storage, if not just cause software data corruption issues, sometimes known as "race conditions" (https://en.wikipedia.org/wiki/Race_condition, https://simple.wikipedia.org/wiki/Race_condition, https://stackoverflow.com/questions/34510/what-is-a-race-condition) in the programmer community similarly, if not watched carefully.

I speak from personal experience having these issues occur, and having read others experiences dealing with the aftermath of the ignorant way some software/repositories is/are blatently run not keeping these risked users in mind.

Before you move folders please be advised and warned there is active heavy machinery (active directories) with moving parts you need to watch carefully for before taking any action.

Risk of www.Snapcraft.io blindsiding users in the middle of a transfer is a catastrophic failure of data loss, from running multiple sync processes for the same data, which if it breaks MySQL (all the time in Cloud data centers), will definitely break a user too.

I commented Move snap packages to another location/directory "Riskwise, does it matter if Snapcraft it [is] active (How to stop snapd from auto-updating?) during Rsync behaviors? Snap does not give predictable timing, and can push random updates during this parallel (r)sync, leading to catastrophic data loss in that important edge case? I edited the script at askubuntu.com/review/suggested-edits/1167854 with sudo systemctl mask/stop/disable snapd.service before, and sudo systemctl unmask/start/reenable snapd.service after, in an abundance of caution."

Originally from my edits at https://askubuntu.com/review/suggested-edits/1167854 & https://askubuntu.com/review/suggested-edits/1168074, which the first was predictably not approved because I said "Snapcraftiness" to describe the terroristic craftiness of the auto-update mechanism. (We went from the deservedly-loved apt-get to snap/snapcraft and it could have been called "snapt" instead to pay homage, somebody thought the ever-so-witty "snapcraft" was a better descriptor so I think my wording Snapcraftiness is accurately best fitting and appropriate coding.

I've used a computer for 25 years and the first year I ever had an program problem was from installing Snapcraft.io and finding it upgrading software which did not lead to any improvement and caused actual degredation in service that the service provider denies in face of loads of user evidence. One day I found that was deeper than a bug, and nearly a hack, fully not standardized officially, describable as an inherent risk to normal/regular users.

These kinds of risks are known to corrupt data, corrupt hard drives, even corrupt entire data center servers when multiple data operations are committed to the same data points, it becomes a physical issue where the is overlapping activity which can ruin physical data storage, if not just cause software data corruption issues, sometimes known as "race conditions" (https://en.wikipedia.org/wiki/Race_condition, https://simple.wikipedia.org/wiki/Race_condition, https://stackoverflow.com/questions/34510/what-is-a-race-condition) in the programmer community similarly, if not watched carefully.

I speak from personal experience having these issues occur, and having read others experiences dealing with the aftermath of the ignorant way some software/repositories is/are blatently run not keeping these risked users in mind.