I've been having problems with files that have the "O" file attribute set. I use Dropbox extensively and I can't figure out how to fix this issue.
The issue arose when I did a search in DO and Dropbox files that should have shown up in the results didn't. With help from the forum I determined this resulted from these files having the "O" attribute set suggesting they weren't actually present on my system. For those who understand Dropbox I have set this PC to keep all files locally. Using DO I was able to determine that 166 of 25000+ files in my Dropbox folder have this attribute set. If I turn off Dropbox I can still access these files which seems to indicate they actually are present on my local drive. Neither DO nor any other program or DOS command etc I have discovered provides me a way to reset this attribute. As long as it's set on random files though it means I can't trust searches or compares or other DO functions that I use.
FWIW I'm continuing to explore this with Dropbox but am interested if anyone else has experienced anything like this. Perhaps could I cause DO to ignore that bit?
Attributes come from the OS and we just display what it says they are.
It's also worth trying the current Opus beta as it has some new workarounds for Windows 10 breaking the cloud storage API, which haven't made it to the non-beta releases yet (but will soon).
Yes the attribute bit "O" is present in File Explorer in same state as what Opus shows. I don't know if Dropbox uses this bit or not (I've asked but not heard back). If not then I don't know what entity actually controls it or what it actually means. Since I can access files that have this attribute set - whether Dropbox is running or not - it seems meaningless. That could mean that Opus might want to provide a way of ignoring this attribute. That would help with my problem.
Are you sure the search you were doing finds the files if they are available locally? e.g. Try copying them to a normal folder. It may be that the search isn't finding them due to a different reason.
I would also try the beta I mentioned, since one of the workarounds it adds fixes a problem introduced in Windows 10 where the status of files on cloud storage is reported incorrectly by the OS.
I have noticed this before. Dropbox seems to use part of the Windows 10 cloud API but not all of it, and does something quite strange with file attributes.
It seems like once a file has been set to online only, the FILE_ATTRIBUTE_OFFLINE attribute gets set and then never gets unset, even if the file is subsequently brought back to local storage. This means you can't reliably use that attribute to determine online/offline status.
Dropbox will also set the FILE_ATTRIBUTE_SPARSE_FILE and FILE_ATTRIBUTE_REPARSE_POINT attributes (with custom reparse data) to indicate when a file is "really" set to online only, and clear them when it's brought back to local storage.
Windows 10 introduced new attributes which the cloud API uses (FILE_ATTRIBUTE_OFFLINE is actually no longer used by things like OneDrive), but Dropbox doesn't seem to use those at all (presumably so it can work on earlier versions of Windows without needing conditional code).
At the moment in Opus I don't think there's really a good way to search for "online only" files in Dropbox, because we don't allow searching on either of the two attributes that it uses.
I have a dropbox(DB) folder that contains 2 text files. One file has the "O" bit set and the other doesn't. If I do a "find" in Opus looking for text, Opus finds the text in the one file but apparently ignores the other file. Since I can open either of these files on the local machine this presents a problem because the search partially fails ostensibly because the file isn't present - but it is. It would be advantageous to be able to ignore that file attribute when performing file operations anything like the find function.
How do I try the beta? Jon do you think that might help?
No the beta addresses problems with things like OneDrive that fully use the cloud API, but it won't affect Dropbox. The problem is Dropbox is lying and telling us the file is offline, so we don't try to search it to avoid bringing the file back from local storage. We have this on the list to try to improve but fundamentally the issue is with Dropbox.
