|Windows||Standard Installer||Offline Installer|
|Mac OS X||Standard Installer||Offline Installer|
|Linux||x86_64 Offline Installer||x86 OfflineInstaller|
Auto-updates: Everyone who chose "Include me on early releases" on the Settings page
This is an early release feature that is subject to these additional terms.
*** I AM REPORTING A SIGNIFICANT AND LASTING BUG IN THIS EARLY RELEASE ***
This BUG will effect any WINDOWS user that has any folder in your dropbox folder with exlicitly assigned windows user permissions. This BUG is sadly in the release version also :(
I post here after contacting DROPBOX directly as they DO NOT UNDERSTAND.
Steps to replicate the fault
Create a "NEW FOLDER" in your dropbox folder.
Add a explicit user permission to the folder "OtherUser with Read & Execute rights"
Add a file to the folder via the web interface or another syncing device.
Check the permission on the uploaded file, no explicit permission exists.
I have completed this and supply an image shoing the folder explict permission for OtherUser and the uploaded via the web interface example file that does not have the explict permission.
I post here as any one would think the Dropbox app was created in germany as it seems that any mention of a fault in a relased version just gets a head buried in the sand reply of "I see nothing!" (Shultz from Hogans Heroes).
Can others please cast your coin if you can replicate this.
Hi there, I dont work for dropbox, but I just stumbled across this post and wanted to ask a question. Since changing permissions on a file created in a folder requires a "full control" token, and your dropbox appears to be running as "DaveCarter" which has full control in the New Folder, have you considered changing administering the New Folder with another account (like DaveCarter_admin) and removing full control rights from DaveCarter, and grant read/write/create only. This way when dropbox creates the file, whatever ridiculousness they are doing that alters the inherited permissions will not be permitted. I am also curious to see if you could post a screenshot of the advanced permissions on a file placed in NewFolder. Does the file have the "Inherit permissions" box checked or unchecked? It seems it must inherit permissions from the parent folder (unless it is a bug in windows). Just my 2 cents.
To clear some things up files are not created in the folders they end up in so "NEW FOLDER" is not the creation location, they are created in C:\Users\DaveCarter\Dropbox\.dropbox.cache\new_files which I display below.
I have added an additional explict permission of the user "LINEUP" to this new_files folder for demonstration purposes . This will show how the permissions of the true creation folder are being maintained but not the destination folder.
The example.png was copied into the new_files folder it was not added by the dropbox app, there files look like a pile of hex characters but appear and disapear so fast its hard to right click on them. They do however have exactly the same permissions as they are created in this folder so inherit the permissions of the folder.
You can see here the LINEUP read permission and the EXAMPLE.PNG that inherited them.
Below is the EXAMPLE.PNG I added to the NEW FOLDER via the dropbox website, it was synced into the local folder by the dropbox application. The COPYIN and MOVEIN files were as they say copied in and moved in with file explorer.
As you can see the EXAMPLE file still has attached its inherited permissions of the creation folder and not those of its destination folder.
What they have done is created the file under one set of permissions and then used the operating systems MOVE function to shift the file without taking into account this does NOT address permissions changes from locations, like File Explorer does do.
To replicate this yourself is easy. Assuming you have a explit permission on the NEW FOLDER (optional one on the NEW_FILES folder)
1) Create 2 files into the "NEW_FILES" folder with explorers right click new text file function, and check their permissions are that of the folder as expected, they will be!.
2) Move file1.txt using explorer into "NEW FOLDER"
3) Move file2.txt using the dos box into "NEW FOLDER"
4) Examine the permissions of the 2 files in "NEW FOLDER", #1 is correct , #2 exhibits the fault I have reported.
* (3) can be performed with the followng two commands
3.1) in file explorers address bar when in NEW_FILES folder type in CMD this opens the dos box in the folder
3.2) enter the dos command> MOVE file2.txt "..\..\New folder"
* the most disturbing thing about all of this is they made this mistake YEARS AGO while in BETA and when reported they stuck their heads in the sand and bull**bleep**ted that it was being investigated, what happened form that you might ask?
THEY LET IT INTO THE MAIN RELEASE
It was corrected a short time later, now they are just doing the same, but its now been in main release for a couple of versions, and what have they done?
STUCK THIER HEADS IN THE SAND AGAIN!
So I tried out what you documented and you are right. It looks like this behavior is a common NTFS Move/Copy design flaw with permissions. I was just reading about people complaining about the exact same issue with direct file system accesses here -- https://serverfault.com/questions/31709/how-to-workaround-the-ntfs-move-copy-design-flaw
I was able to reproduce the exact behavior without dropbox as part of the mix and I think I have a workaround that might work for you as well without having to run icacls over and over again. I don't know what dropbox did to fix the issue in the previous build (but I probably dont want to know).
One of the ideas in the stackoverflow article was to use some mounted file system trickery to force the move operation to go to another NTFS file system. Here's what I did.
First, create a new NTFS volume. I did this by using a USB stick and formatting it NTFS. Then I mounted it in my dropbox directory like so.
Next, I adjusted the permissions on the "Good" volume as so.
Then I repeated the move test, first with 'bad' and then 'good'.
The "bad" ...
Now the "good" ...
Seems to work. Now with dropbox.
And now for the "ugly"... I can't test it with dropbox at the moment because its busy re-indexing all my dang files after this update. :-(
I'll be back with the results when this is done, in about a half hour.
Thanks I did know how to create the multi volume work around, and it does work, of course its a cludge that has some issues I wont go into. Besides saying its a cludge!
And on our system I really woudnt like to perform it with 2TB+ @ 750kfiles ranging in size from 0 to 15gb+. As across volume MOVES are just COPY/DELETE, and the use of the hidden cache folder building the file was specific to prevent a copy in delay before access.
And its not like its hard to apply the folder permisisons to a file moved into it in code, they should just do it. Like they used to, but then have had soemone else recode the whole back end sync and they miss it.
We have 8 network share points into the dropbox folders and 28 different permission sets across them, right now the icacls task is good enough its not stressing the servers.
If we had hundreds I would just code a service to run on the file notification events (like dropbox uses), and adjust the permissions as needed when the file appeared. But im just not going to cludge for them again. I mean it isnt overly hard to do one, I wrote one that monitered the open files on a machine then updated a openfileslist file in a dropbox folder, that DB synced between machines,then each machine doing this also read the other machines openfileslist and locked all those files also. Caught 99% of multiple machines opening the same file, but there was a window of opertunity for it if 2 machines opened at the same time and a lag after closing, as the openfileslist files while small still could take a minute to sync. I started to rewrite it to use hidden folders replicating the whole path to the file which was looking promising It would have been nice, an example of it was say the file c:\users\name\dropbox\folder\file.ext was opened then a folder named c:\users\name\dropbox\.OF\folder\file.ext was generated by that machine, that folder would replicate acoss all machines near instantly and any other machine would see this then lock the files the folder represented (.OF for Open Files). I was still covering the issues of machines dropping off leaving ophaned folders when I abadoned it as our need reduced to near nill as we shifted to OneDrive/Office365/Sharepoint which suppiorted file locking from the cloud.
And now im rabling! LOL!
Quite an operation you have going there, lol!
My dropbox is now "syncing". My other computer has been "syncing" all day, and now this one is "syncing". Doesn't give much feedback on what its doing. Procmon shows it churning through lots of hash files. Not sure what the deal is with this latest update. I hope it completes eventually.
Anyway, good luck, maybe in the future dropbox will add a "rehash file permissions" option or something for you!
The stable builds are for the Desktop client, which is regularly updated with many improvements and fixes.
A beta build is an early release feature that is subject to these additional terms.
If you need more help you can log a ticket with our Support Team here (expected response time 24 hours), or contact us on Twitter or Facebook.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!