I have a situation that I need help with. Why is Dropbox changing file attributes? Any file I mark as "read only" is toggled back to write-enabled.
Now, I can understand that dropbox needs write permission to sync files but this should be done as admin rights maintaining the same user. In my cases, I auto-generate my linux init files (.bashrc, .profile etc) from an org file and I need to make these files readonly so I don't edit them directly. They reside in dropbox as they are used on multiple machines. When I edit the master init file repo and export the init files, they are indeed 0444 for a second or two then switch back to 0644. This is very bad!
This doesn't help at all. Dropbox should not be modifying read only files to writable. If it's the case that Dropbox is incapable of copying the original user attributes on a file this is a serious shortcoming. I understand it runs as user but I would think that it could temporarily override the readonly and replace and reapply.
Dropbox should never ever alter a file's attributes.
Better it simply does nothing if it can't sync a readonly file.
I am having a similar issue with files being produced by a process managed with the root user. The resulting files are placed in the Dropbox folder. When I open the folder with Nautilus, I see the files looping every 2-3 seconds between the green tick (sync complete), the blue syncing arrows (sync undergoing) and a lock icon (not owned by the non root user). Also sometimes I see the red cross (sync failure). What is the solution? I don't want to change the ownership of the files because it's a way to protect them from the non root users in the system...
I am just realizing now this might be due to some other process that keeps changing the modification time of the file (even though the content stays the same). This is enough to trigger the Dropbox daemon (which is ok), so probably is not a Dropbox issue in my case