Issue with DropBox 1.2.49 Update

May not be an Addon issue: http://www.readynas.com/forum/viewtopic ... 36&t=59500

Also references to ".AppleDouble" may possibly indicate that DropBox doesn't work nicely with Netatalk. I don't access the DropBox folder on my NAS via AFP. I use CIFS.

mdgm wrote:
Also references to ".AppleDouble" may possibly indicate that DropBox doesn't work nicely with Netatalk. I don't access the DropBox folder on my NAS via AFP. I use CIFS.

I would have accepted this if it had been an issue with 1.2.48. I only access my NAS user home via AFP. So if /that/ was the problem, then it'd have shown up instantly. No need to wait for an upgrade. ;)

sphardy wrote:
May not be an Addon issue: http://www.readynas.com/forum/viewtopic ... 36&t=59500

Well... still, this doesn't explain why this odd behavior with 1.2.49, even if 1.2.48 just stopped being recognized. In fact, I wouldn't have bothered to even pay for the upgrade if the addon hadn't stopped processing updates.

I may create an additional sandbox in order to properly test this business... I'm just not ready to trust it again with live production stuff.

Went ahead and created the sandbox for the global dropbox config. I can definitely confirm that when 1.4.28 syncs it DOES NOT include any .dot files or directories. 1.4.29, on the other hand, seems to do so readily.... and erroneously, IMO.

What I think /may/ be happening when I saw the thrashing of adds/deletes previously is that, with my personal dropbox, I have multiple clients, including my own local Mac account. I wonder if the Mac client wants to inhibit the .dot files and tries to delete them when they show up, but 1.4.29 wants to add them because it thinks they should be there.

That condition doesn't exist for this global dropbox setup, so therefore no thrashing.

So the choices now seem to be a client that doesn't continue to sync (1.4.28) or this one that syncs more than it should, and creates bad interactions with other clients linked to the same dropbox.

btaroli wrote:
mdgm wrote: Also references to ".AppleDouble" may possibly indicate that DropBox doesn't work nicely with Netatalk. I don't access the DropBox folder on my NAS via AFP. I use CIFS. I would have accepted this if it had been an issue with 1.2.48. I only access my NAS user home via AFP. So if /that/ was the problem, then it'd have shown up instantly. No need to wait for an upgrade. ;)

I think you misunderstand my post - the .AppleDouble folders are sync'ed and are then visible via the dropbox web interface, but are not typically visible on your mac which always treats such files as hidden. This is simply a fact - true as of dropbox version 1.2.48 - and not a claim that it may be a cause of the problem you are facing

sphardy wrote:

btaroli wrote: mdgm wrote: Also references to ".AppleDouble" may possibly indicate that DropBox doesn't work nicely with Netatalk. I don't access the DropBox folder on my NAS via AFP. I use CIFS. I would have accepted this if it had been an issue with 1.2.48. I only access my NAS user home via AFP. So if /that/ was the problem, then it'd have shown up instantly. No need to wait for an upgrade. ;) I think you misunderstand my post - the .AppleDouble folders are sync'ed and are then visible via the dropbox web interface, but are not typically visible on your mac which always treats such files as hidden. This is simply a fact - true as of dropbox version 1.2.48 - and not a claim that it may be a cause of the problem you are facing

'cept the problem is that I can observe that 1.2.48 /didn't/ sync them to dropbox, even if present. Observable and repeatable.

btaroli wrote:

sphardy wrote: btaroli wrote: mdgm wrote: Also references to ".AppleDouble" may possibly indicate that DropBox doesn't work nicely with Netatalk. I don't access the DropBox folder on my NAS via AFP. I use CIFS. I would have accepted this if it had been an issue with 1.2.48. I only access my NAS user home via AFP. So if /that/ was the problem, then it'd have shown up instantly. No need to wait for an upgrade. ;) I think you misunderstand my post - the .AppleDouble folders are sync'ed and are then visible via the dropbox web interface, but are not typically visible on your mac which always treats such files as hidden. This is simply a fact - true as of dropbox version 1.2.48 - and not a claim that it may be a cause of the problem you are facing 'cept the problem is that I can observe that 1.2.48 /didn't/ sync them to dropbox, even if present. Observable and repeatable.

I've been trying this back and forth with 1.2.48 and 1.2.49 for hours now and the behavior of both versions for me is exactly the same:

If you access a Dropbox that is on your local hard drive on a Mac, the .AppleDouble folders won't be synced, that's correct. However, if you access a Drobox folder that is shared using AFP from a Mac, the .AppleDouble folders will be created in the share *and* will be replicated. I could reproduce this for 1.2.48 and 1.2.49. Now if you happened to have a local Dropbox with local .AppleDouble folders, the Dropbox daemon would of course delete/update/replace your local copies because of that replication.

So my conclusion right now is that somehow the Dropbox daemon detects that it is running on a Mac and if it is, it won't replicate .AppleDouble and what other special stuff the Mac creates TO the network. However, since the ReadyNAS isn't a Mac, the daemon there will detect those files/dirs as soon as they are created through an AFP client connection and then replicate them. Now if you access the Dropbox using multiple Mac clients you will most likely receive a constant stream of update/delete/create messages.

But right now I don't see how this is a problem caused by the add-on , nor is there a chance to fix it through it. And as I said: for me even 1.2.48 behaves that way.

Now I may totally misunderstand the problem here, so if I do please give me more feedback so I can better understand and mirror the setup.

-Stefan

Stefan - what you describe is exactly the behaviour I have seen across v1.1.x and 1.2.x versions of the client - it has never caused a real issue, just a minor annoyance when using Dropbox in a non Mac environment including via the web interface

FYI: My NAS install has now indexed everything and seems to be running happily again

I just noticed that dropbox appears to have removed their wiki pages - wiki.dropbox.com now just redirects to the dropbox blog.

The wiki provided access to a number of useful but unsupported utils including a python script that provides commandline control of the dropbox client. I've uploaded the script here - might be useful others to create a status check script