This problem seems to be linked to "the Turkish issue" (involving both dotted and non-dotted versions of i). There is some kind of duplicate checking mechanism in Dropbox to side step problems with case insensitive file systems. In site of their claim to full UTF-8 support there is at least one bug affecting syncing of folders that contain characters that don't convert from upper to lower case and back round trip using generic algorithms.
Removing all content with the non English ı
and İ
characters solves this sync issue.
Once everything is in sync again across platforms, adding the content back in as find as long as there is there is not a file that would be ambiguous giving a non-case sensitive file system and a case conversion involving those letters.
Ok, here is the solution I have found. Whether or not this will work with future versions of Dropbox is uncertain. I have opened a service request with Dropbox to try to resolve the problem further.
Overall, the solution is a combination of two things:
- Setting the umask for the Dropbox process so that newly created files have permissions of 0660. This is user read/write, group read/write, other none.
- Setting the group for newly created files to the group that needs to have write access to the files in question.
This solution will apply to all files in the Dropbox folder, not just a single file. In my case this is acceptable.
Under Linux, I modify the /etc/init.d/dropbox
startup script so that the line invoking dropbox as a daemon reads:
HOME="$HOMEDIR" start-stop-daemon --umask 0006 -b -o -c $dbuser:$dbgrp -S -u $dbuser -x $HOMEDIR/$DAEMON
Adding the --umask 0006
accomplishes setting the umask, and the :$dbgrp
portion of the -c option accomplishes setting the group to that the daemon belongs to.
On the Mac side, I run the following commands:
ps aux | grep -i dropbox
From this I can see the command-line options that started Dropbox and from this I extract the $mydropboxid used later. Then I quit Dropbox and open a command prompt and enter the following commands:
umask 0006
/Applications/Dropbox.app/Contents/MacOS/Dropbox -psn_0_$mydropboxid &
exit
I plan to automate the above commands at some point so that I won't have to re-run these any time my machine is rebooted.
This handles setting the mask for newly created files so the group for a file has write access. However, in order to get the group set correctly I need to setgid the Dropbox cache directory - this so far has only needed to be done once:
sudo chgrp -R $dbgrp ~/Dropbox/.dropbox.cache
sudo chmod -R g+s ~/Dropbox/.dropbox.cache
It appears that all new files are first created under the ~/Dropbox/.dropbox.cache directory, so the above commands gives those new files the proper ownership and permissions that new files created by Dropbox has the correct group.
Best Answer
The HFS+ filesystem includes
flags
, which provide extra permissions on top of the usual Unix permissions. One of the flags is "unchangeable" - which does what the name suggests.Several files inside my dropbox had been flagged as
unchangeable
. You can check for this with ls:-0
tellsls
to show the extra flags;uchg
indicates that this files in unchangeable.To fix this, use
chflags
: