Linux... move the Dropbox Folder

Hi cipherguru,

I have no idea what exactly you are doing, but I can show you what's going on in my case. :wink: "Workaround" script is installed and Dropbox runs. Follows some commands executed exactly in sequence (and the corresponding results):

$ mkdir ~/ATestDir ~/Dropbox/ATestDir
$ echo "Just some text for test. ;)" > ~/ATestDir/test.txt
$ ls -l ~/ATestDir
> общо 12
> -rw-r--r-- 1 zdravko zdravko 28 мар 11 15:30 test.txt
$ ls -l ~/Dropbox/ATestDir
> общо 0
$ sudo mount --bind ~/ATestDir ~/Dropbox/ATestDir
$ ls -l ~/Dropbox/ATestDir
> общо 12
> -rw-r--r-- 1 zdravko zdravko 28 мар 11 15:30 test.txt
$ dropbox filestatus ~/Dropbox/ATestDir/test.txt 
> /home/zdravko/Dropbox/ATestDir/test.txt: up to date

Is this not working?! i.e. a file created and existing outside Dropbox directory (file test.txt in "~/ATestDir" in particular) is mapped to and in sync in the Dropbox directory ("~/Dropbox/ATestDir" in particular), very similarly to a symbolic link. Review what you are doing! The only thing which have to be corrected is the forum bug (I emphasize here "FORUM") related to one variable name (which you declare done). That's it, nothing more.

Good luck.

I'm unable to use this from outside the home folder

tim@hn:~$ mkdir ~/BTest ~/Dropbox/BTest
tim@hn:~$ echo "Just some text for test" > ~/BTest/test.txt
tim@hn:~$ sudo mount --bind ~/BTest ~/Dropbox/BTest
tim@hn:~$ dropbox filestatus ~/Dropbox/BTest/test.txt
/home/tim/Dropbox/BTest/test.txt: up to date

tim@hn:~$ mkdir ~/CTest ~/Dropbox/CTest ~/DTest
tim@hn:~$ echo "Just some text for test" > ~/DTest/test.txt
tim@hn:~$ sudo mount --bind ~/DTest ~/CTest
tim@hn:~$ sudo mount --bind ~/CTest ~/Dropbox/CTest
tim@hn:~$ dropbox filestatus ~/Dropbox/CTest/test.txt
/home/tim/Dropbox/CTest/test.txt: up to date

tim@hn:~$ mkdir ~/ETest ~/Dropbox/ETest /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest
tim@hn:~$ echo "Just some text for test" > /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest/test.txt
tim@hn:~$ sudo mount --bind /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest ~/ETest
tim@hn:~$ sudo mount --bind ~/ETest ~/Dropbox/ETest
tim@hn:~$ dropbox filestatus ~/Dropbox/ETest/test.txt
/home/tim/Dropbox/ETest/test.txt: unsyncable

tim@hn:~$ mkdir ~/Dropbox/GTest /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest
tim@hn:~$ echo "Just some text for test" > /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest/test.txt
tim@hn:~$ sudo mount --bind /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest ~/Dropbox/GTest
tim@hn:~$ dropbox filestatus ~/Dropbox/GTest/test.txt
/home/tim/Dropbox/GTest/test.txt: unsyncable

What are these intermediate mount point for (i.e. "~/CTest" and "~/ETest" in your examples)? They are meaningless. Only increases the load to some extent, nothing more. Are you sure the owning and access rights are set as needed on the other storages (i.e. to you)? I can't see a result from commands like:

ls -al /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest
ls -al /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest

And to be sure what exactly gets mapped, check too:

ls -al ~/Dropbox/ETest
ls -al ~/Dropbox/GTest

Here is the info you need plus a bit more.. hope some clue here. Intermediate mount points to show that nested bind mount works in certain cases and not others.

tim@hn:~$ ls -al /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest
total 12
drwxrwxr-x  2 tim tim 4096 Mar 12 01:24 .
drwx------ 22 tim tim 4096 Mar 12 01:25 ..
-rw-rw-r--  1 tim tim   24 Mar 12 02:07 test.txt

tim@hn:~$ ls -al /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest
total 12
drwxrwxr-x  2 tim tim 4096 Mar 12 01:25 .
drwx------ 22 tim tim 4096 Mar 12 01:25 ..
-rw-rw-r--  1 tim tim   24 Mar 12 02:07 test.txt

tim@hn:~$ ls -al ~/Dropbox/ETest
total 48
drwxrwxr-x   2 tim tim  4096 Mar 12 01:24 .
drwxrwxr-x 440 tim tim 32768 Mar 12 02:07 ..
-rw-rw-r--   1 tim tim    24 Mar 12 02:07 test.txt

tim@hn:~$ ls -al ~/Dropbox/GTest
total 48
drwxrwxr-x   2 tim tim  4096 Mar 12 01:25 .
drwxrwxr-x 440 tim tim 32768 Mar 12 02:07 ..
-rw-rw-r--   1 tim tim    24 Mar 12 02:07 test.txt

tim@hn:~$ cat /mnt/74bcf733-f29b-42db-bedd-1882056fb822/FTest/test.txt
Just some text for test

tim@hn:~$ cat /mnt/74bcf733-f29b-42db-bedd-1882056fb822/GTest/test.txt
Just some text for test

tim@hn:~$ cat ~/Dropbox/ETest/test.txt
Just some text for test

tim@hn:~$ cat ~/Dropbox/GTest/test.txt
Just some text for test

tim@hn:~$ mount | grep 74bcf733
/dev/mapper/luks-60d82ae3-53f5-4e69-adea-98fa841b015c on /mnt/74bcf733-f29b-42db-bedd-1882056fb822 type ext4 (rw,nosuid,nodev,relatime,data=ordered)

tim@hn:~$ cat /etc/fstab | grep 74bcf733
/dev/disk/by-uuid/74bcf733-f29b-42db-bedd-1882056fb822 /mnt/74bcf733-f29b-42db-bedd-1882056fb822 auto nosuid,nodev,nofail 0 0

Hi cipherguru,

Yes, you are right. Unfortunately seems Dropbox had changed their way to check used FS. Some time ago the check was independent for every one FS element (file or folder). Now seems full FS check is performed only for the Dropbox folder, itself; further, the folder content is checked to be part of the same block unit. This second check is something new and will affect any mount of something outside current block unit (real or virtual), don't even need to be another drive or partition. Dropbox doesn't try extend application feature set, but make users life heavier instead, again! Long time I hadn't used such type of mounts. Have to be considered this case (current workaround still work, but should to be extended to cover the case). If you have a time, while keep current solution, try find and reimplement other "guilty" functions (in the same way as those already swapped). I will try take a look when possible.

Good luck.