Re-mount partition that contains Dropbox folder

[raffaem]

I have my Dropbox folder in /run/media/user/XXX/Dropbox.

Where XXX is the mountpoint of the partition.

I have to remount the partition to /run/media/user/YYY.

What is the correct procedure to make maestral aware of the mount point?

[samschott]

Ah, that's a tricky one. There currently is no user-friendly way to do this. Both the CLI command maestral move-dir and the GUI option assume that both the source and destination path are writable and readable when moving the folder.

Your best option is to stop Maestral, change the config value directly, for example by running

$ maestral config set path "/run/media/user/YYY/Dropbox"

or by editing the config file, then remount the partition and restart Maestral. It should seamlessly restart where it left off.

[raffaem]

I did that but it's indexing local changes....

[samschott]

Ah, damn. It worked for me when moving folders manually on the same drive.

I remember there was an issue when moving the folder between drives could cause a change in ctime and therefore a reindexing of all files, I deliberately moved to using the mtime instead as a result. There might be something similar going here as well...

[raffaem]

Ah, damn. It worked for me when moving folders manually on the same drive.

I remember there was an issue when moving the folder between drives could cause a change in ctime and therefore a reindexing of all files, I deliberately moved to using the mtime instead as a result. There might be something similar going here as well...

Sam, it completely messed up and destroyed by remote Dropbox folder organization.

I thought that in:

maestral config set path "/run/media/user/YYY"

I would have to pass the path WITHOUT the ending "Dropbox" folder, like you do when you set up Maestral for the first time.

Instead it's the path WITH the ending "Dropbox".

It upload all my harddrive on Dropbox and destroyed the real Dropbox folder (the remote one, the local one fortunately it's sane).

I have no idea how to recover from that.

[samschott]

Oh shit, I am so sorry about that! Yes, the provided path should indeed be the path of the new folder itself, this was my mistake when providing you with the instructions. This does explain the unexpected indexing, you must have a large Dropbox quota to fit the entire drive.

If you do not have any shared folders in your Dropbox, recovering from this should be relatively straight forward, since the local version of the Dropbox folder is still fully intact (as is the now uploaded version of it, albeit at a folder called "Dropbox" inside your Dropbox). The following steps should avoid further unnecessary data transfer:

1. Unlink Maestral.
2. Remove all folders apart from "Dropbox" on the Dropbox website.
3. Move all folders from inside "Dropbox" to the top-level.
4. Delete the "Dropbox" folder on the Dropbox website.
5. Re-link with Maestral, selecting the still intact local folder. Reindexing will take place but should not result in any conflicting copies.

If you do have shared folders, the situation is more complex: They will have been "deleted" (unmounted) from your Dropbox, though ideally their content should still be intact since Maestral handles nested deletions by only deleting the top-level item on Dropbox servers. The solution here will be:

1. Unlink Maestral.
2. Remove all folders apart from "Dropbox" on the Dropbox website.
3. Go to "Shared" on the website and re-add those that have been "deleted" / unmounted.
4. Move all other folders from inside "Dropbox" to the top-level.
5. Delete the "Dropbox" folder on the Dropbox website.
6. Re-link with Maestral, selecting the still intact local folder. Remote items from shared folders will trigger conflicting copies if the remote version has changed in the meantime.

Either path will require some amount of manual work, unfortunately. Also, please make a backup of the local Dropbox folder before resyncing!

[samschott]

Also, note to myself: double-check what I have written when providing hacky instructions.

[raffaem]

I have a problem.

It actually did NOT upload all my hard drive to the remote Dropbox folder.

Some remote folders are empty, while being non-empty in my local hard drive.

maestral status shows sync errors:

$ maestral status

Account:      XXX@XXX.XXX (Business)
Usage:        XXX% of XXX TB used
Status:       Connected
Sync errors:  1

Path                          Error
/XXXX/XXX            Could not upload file. The destination path is
                              invalid. Paths may not end with a slash or
                              whitespace.

Also the maestral taskbar icon turns from white to gray and back to white repeatedly.

---

If you do have shared folders

I am in this situation. I do have shared folders.

They will have been "deleted" (unmounted) from your Dropbox

There are two kinds of shared folders.

The remote folders I did not downloaded on my local hard drive, are still present in the remote Dropbox folder.

The remote folders I did have downloaded to my local hard drive, are not present in the remote Dropbox root folder. Instead they are present inside the remote /Dropbox (INSTITUTION) folder, although are not shared anymore.

ideally their content should still be intact

Where they should be still intact?

My co-workers did not notice a deletion of their remote Dropbox folder shared with me. So these remote folders got deleted from my remote Dropbox root folder, but still live somewhere inside Dropbox drives?

Maestral handles nested deletions by only deleting the top-level item on Dropbox servers

I have no idea what that means

3. Go to "Shared" on the website and re-add those that have been "deleted" / unmounted.
4. Move all other folders from inside "Dropbox" to the top-level.

In the meantime I have made changes to those shared folders on my local harddrives.

What will I do with that?

Will Maestral overwrite my changes with the remote Dropbox version? (bad)

Or will it upload the new changes to Dropbox? (good)

Either path will require some amount of manual work, unfortunately.

The important thing is that I can recover from that :)

---

you must have a large Dropbox quota to fit the entire drive.

I am astonished as well. I was reluctant to keep remote backup copies of my data due to privacy concerns but also supposedly quota restraints.

The good thing is that I now know my data fit perfectly on remote.

And I don't have privacy concerns anymore now that Maestral uploaded all my data on the web :)

Apart from that, I have discovered a software that can make encrypted backup copies.

---

Also, note to myself: double-check what I have written when providing hacky instructions.

For the future maybe we can have something like that:

1. On the Maestral taskbar icon, you click on "Freeze"
2. Maestral writes a file in the local Dropbox folder, maestral_freeze_blahblah.txt, with a random string inside
3. Maestral unlinks
4. You move around the folder and do whatever you want
5. You click on "Unfreeze" and select the new folder
6. Maestral checks the file is there, and checks the string inside it is what it knows it should be
7. If so Maestral removes the file and re-link

[raffaem]

maybe that file inside the Dropbox folder should be made permanent, and should be checked every time that Maestral starts, as a robustness check that everything is right and the folder is not messed up and linked to something else.

Maybe Maestral should have someway to find out, when it starts, whether the folder it is seeing is "substantially" different from what it saw the last time, and prompts the user if so. "substantially" is arbitrarily defined.

[raffaem]

P.S. how is it that my local folder survived, and the remote changed?

How did Maestral find out that my local changes where "more recent" than the remote ones, although the mtime of the files did not change? (at least I think so, I just remounted it)

[raffaem]

$ maestral config set path "/run/media/user/YYY/Dropbox"

Ah, you put the Dropbox at the end now that my folder is messed up.

Thank you, Sam.

[samschott]

Well, yes, just in case someone else reads the instructions!

[raffaem]

Well, yes, just in case someone else reads the instructions!

I'm messing up with you Sam :)

[raffaem]

Sam, I nuked the local folder that caused the sync error.

Now maestral status shows:

$ maestral status

Account:      XXX@XXXX (Business)
Usage:        XXX% of XXX TB used
Status:       Connected
Sync errors:  0

and, cd-ing on the root local Dropbox folder, filestatus shows:

$ maestral filestatus .
up to date

BUT, using the Dropbox web interface, I still realize there are some folders which are empty in the remote repo, but full on my local hard drive.

What to do?

And how I can make sure the /Dropbox subfolder of the remote repo got synced correctly?

[raffaem]

ok, now filestatus is on uploading. Including inside the local Dropbox folder.

What to do?

I cannot exclude the folders I don't want to sync. It tells me to try again when idle.

Do I have to wait until all the folders get uploaded?

That would require a lot of time (and privacy concerns)

[samschott]

From your comments, I've tried to follow what state your Dropbox folder is in at the moment, but I am note quite sure that I got it right. So just to answer your questions:

Maestral handles nested deletions by only deleting the top-level item on Dropbox servers

I have no idea what that means

That means that Maestral does not delete anything inside those shared folders, it just unmounts them from your Dropbox but they live on in other people's Dropboxes.

Where they should be still intact?

My co-workers did not notice a deletion of their remote Dropbox folder shared with me. So these remote folders got deleted from my remote Dropbox root folder, but still live somewhere inside Dropbox drives?

You can view them by navigating to "Shared" in the navigation sidebar on the Dropbox website and from there add them again to your Dropbox.

The remote folders I did not downloaded on my local hard drive, are still present in the remote Dropbox folder.

Yes, that is expected. Maestral won't touch remote folders which are excluded by selective sync.

In the meantime I have made changes to those shared folders on my local harddrives. What will I do with that? Will Maestral overwrite my changes with the remote Dropbox version? (bad) Or will it upload the new changes to Dropbox? (good)

It will create conflicting copies for those because, after unlinking and relinking, it will not have authoritative information to indicate which version is newer.

And how I can make sure the /Dropbox subfolder of the remote repo got synced correctly?

There will be sync errors for every item which did not get synced correctly.

[samschott]

So, what state is your Dropbox folder currently in now? Did you follow the instructions which start by unlinking Maestral first? You can do this without waiting for your entire drive to be uploaded completely, in case there are any pending items to sync. Since you still have all items intact in the local "/run/media/user/YYY/Dropbox" folder, any of those which did not completely upload yet will just be uploaded after relinking later.

As stated in the above instructions, before linking, make sure to recreate the intended folder structure on the website:

1. Delete any erroneously uploaded top-level folders.
2. Remount any unmounted shared folders.
3. Move any folders from inside the "Dropbox" folder back to the top-level.
4. Delete the now empty "Dropbox" folder.

After relinking, any changes to files will trigger conflicting copies which you will need to clean up manually. Any new items, whether local or remote, will be synced without issues.

[raffaem]

Sam,

I followed the instructions you posted in the case the user have shared folders, which I do.

It is now downloading all the folders I had excluded with selective sync, since there seems to be no selective sync when you link the account (?)

Also I noticed, when you link it, you now have to input the /Dropbox subfolder. I think you had to input the parent of that folder in a previous version.

Let's hope for the best!

[samschott]

since there seems to be no selective sync when you link the account (?)

That's strange, there should still be a selective sync panel during setup.

Also I noticed, when you link it, you now have to input the /Dropbox subfolder. I think you had to input the parent of that folder in a previous version.

Yes, this was a popular request by users who wanted to choose their own folder name. I held off on this for a while for fear that it might be confusing (and lead to potential uploads of the entire home folder...). I hope that with the current wording and warning dialogs when selecting a non-empty folder it should be safe now.

Let's hope for the best!

Fingers crossed. And apologies for the mess!

[raffaem]

I can't get around understanding how to find out if Maestral has finished to sync.

maestral status shows Connected, so it doesn't show Syncing which is what would show if it were syncing (I think). But, 2 seconds after that, maestral filestatus . on the DropBox folder shows uploading. It would show uptodate if it were up to date. And maestral log show (at the debug level)'s last entry is from one hour ago.

On a side note, I cannot permanently delete the files on my remote repo. It looks like my organization has prevented team members from permanently deleting files.

Sam, have you thought about my suggestion of a hidden file inside the Dropbox folder that would allow Maestral to find out whether the folder exposed to it it's the right one?

One could mess this up in various way (unmounting/remounting on Unix, or changing drive letters on Windows, or by having the folder in an external drive and connecting a different one).

[samschott]

maestral status shows Connected, so it doesn't show Syncing which is what would show if it were syncing (I think). But, 2 seconds after that, maestral filestatus . on the DropBox folder shows uploading. It would show uptodate if it were up to date. And maestral log show (at the debug level)'s last entry is from one hour ago.

That is indeed an unusual state. When idle, maestral status should show "Up to date", as should maestral filestatus DROPBOX_PATH. Pausing and resuming sync should hopefully fix any inconsistencies in returned status.

On a side note, I cannot permanently delete the files on my remote repo. It looks like my organization has prevented team members from permanently deleting files.

Damn, I'm sorry about that :/

Sam, have you thought about my suggestion of a hidden file inside the Dropbox folder that would allow Maestral to find out whether the folder exposed to it it's the right one?

Yeah, I like the idea, though I can imagine cases where a user could accidentally or deliberately delete such a file and face unintended consequences. The idea of validating the folder location besides just checking the path makes sense though, precisely for the use-case changes in mount point.