confirmation should be asked before removing U1 folder from server

[Lionel Dricot]

I use Ubuntu One for a lot of documents, in the Ubuntu One folder and, now that the feature is available, in some other folder.

Today, at work, I received a new laptop. I then moved, with SSH, all my folders from my old laptop to the new one. I moved because the old laptop will be given to someone else. Those folders include the Ubuntu One synced folders. I just didn't realize (I was also thinking that U1 was not bypassing the proxy at work. I was wrong).

Then, I now realized that all my U1 folders are empty on the new laptop ! When moving, the order to delete the file was sent to U1.

Hopefully, I have a third laptop with my U1 files but I have to be very careful and I have to boot it without any network connection. If not, I will have to fall back on the good old 2 months old disk backup. Also, it's a chance that my partner is not at home today, because she would have used that laptop and I would have lost a lot ! (I only lost part of my work today, including my GUADEC registration)

There is something very wrong here. I think that some protection mechanisme should be set. When deleting a folder which is a U1 root, a confirmation should be asked before removing the whole folder from the U1 server.

Worst : there's are worse catastrophic scenarios. Just imagine that you stay logged at home and your partner has administrative rights on it. He login into his own session then, by mistake, do a rm -rf /. You will then see suddenly all you files disappearing from your computer at work without any way to restore them ! What a nightmare !

[Duane Hinnen (duanedesign)]

Lionel,
I appreciate your frustration, it is never fun to lose data. In the use case where you are cleaning off an old computer I would recommend removing it from your Ubuntu One account before removing data. This would prevent Ubuntu One from receiving the 'delete' command. Your recommendation for a 'are you sure?' dialogue is a nice idea. I have updated the title of the bug to reflect this.

When sharing data with co workers I would recommend sharing a folder with that user instead of granting full access to your Ubuntu One account. You would still lose the shared folder but not the entire Ubuntu One folder. You can sharre any folder synced by Ubuntu One by r-clicking and selecting 'Share on Ubuntu One' https://wiki.ubuntu.com/UbuntuOne/Tutorials/FileSharing#Sharing

Thank you again for sharing your use cases and ideas. These are very helpful for future development of Ubuntu One.

thank you,
duanedesign

[Lionel Dricot (ploum-deactivatedaccount)]

Duanedesign > I perfectly understand what I should have done. But the fact that I was tricked (and I a computer geek) is the proof that there's a need to prevent incident like this.

Hopefully, I recovered most of my datas by rebooting my third laptop without any connection. But I was close ;-)

Now, I think it's really important to prevent this from happening because I think that this is a very common use case :

1) receive a new laptop
2) copy everything on the new laptop from the old one
3) checking that everything is fine on the new one.
4) a few day later, removing files from the old one in order to give that old laptop to someone else.

If the "removing files" bit is done while logged in, you will also remove file from your U1 account and thus from your new laptop.

This look a very "normal" pattern and, thus, should not have any major repercussion.

I think that warning before removing a folder might be enough, with the following options :

- Cancel, I don't want to remove that folder
- Remove it only from that computer and don't sync with U1 account (= U1 sync will be disabled on this computer)
- Yes, remove it from that computer and from my U1 account. I understand it will be removed from any computer in sync with my U1 account.

Maybe the confirmation should be opened in a webpage ?

[John Lea (johnlea)]

The UX spec that defines the future functionality regarding "moving a folder out of a Ubuntu One enabled folder" is available at http://use-case-mapper.canonical.com/specifications/0AU5sFuLRpCpBZGZra2pqY2pfMjY1ZjRodG5nZDg/use_cases/2_7

(remember to view variations 1.a, 2.a and 3.a - links are on the left hand side of the Use Case Mapper)

This use case will not prevent the problem you encountered from happening, but I would be interested any suggestions you might have. The problem we are facing is that if we issue a warning every time you delete or move a file out of a Ubuntu One enabled folder most users will quickly become annoyed and would switch the warnings off. Then we are in a situation where we have both annoyed lots of people and not solved the problem ;-)

One possible solution could be to treat the deletion of any UDF as the same as pressing the soon to exist "Cancel sync" button. This would stop the syncing of the folder to the specific computer but would not remove the folder from the cloud. However only partially solves the problem.

Suggestions??? Ideally in use case format please ;-)

[Lionel Dricot (ploum-deactivatedaccount)]

John > What about warning only when deleting the folder at the "root" of U1 user ?

Lionel has an "Ubuntu One" folder and another folder called "Pictures" that is synchronized with his U1 account.

Lionel delete a file in one of those folder : the file is immediatly deleted.
Lionel delete Pictues/Trip in Spain folder : the folder is immediatly deleted with all the content
Lionel delete the Pictures folder (which is a "root") :

a warning appears :

"You have choosen to remove "Pictures", which is synchronized with your U1 account.
- Cancel, I don't want to remove that folder
- Remove it only from that computer and don't sync with U1 account (= U1 sync will be disabled on this computer)
- Yes, remove it from that computer and from my U1 account. I understand it will be removed from any computer in sync with my U1 account."

I believe that this will fix my usecase, or at least make it a lot less dangerous while, in the same time, will not be annoying to U1 users.

[John Lea (johnlea)]

Lionel > Agreed, that would work. Requires a infrastructure element we don't have at the moment but need to build to solve quite a few other use cases ('File manager interaction' e.g. the ability to intercept file manager requests and pause and sometimes cancel actions). I'll update the spec - thanks!

Another reason why we need to do the work to make 'file manager interaction' possible ;-)