Somehow we now have the issue that the gem won't get all changes and therefore files are missing.

The last entry in the log is

D, [2014-10-07T10:39:05.110118 #2466] DEBUG -- : Executing changes:

(nothing after this but before this life everything seems to be okay) and the returned result is empty:

:002 > Dbox.pull ...
 => [{:created=>[], :deleted=>[], :updated=>[], :failed=>[]}]

Is there any recommended way of investigate errors like this (it is not possible for us to give out credentials with the data causing this 😿)?

UPDATE:

It seems that the issue is an case error.

I removed the complete local dropbox folder & tmp files and pulled again.
The first time i will get an exception:

Errno::ENOENT: No such file or directory @ rb_file_s_mtime - /home/www-data/dropbox/Assets/hi/COVER
        from [..]/vendor/bundle/ruby/2.1.0/gems/dbox-0.8.2/lib/dbox/syncer.rb:85:in `mtime'
        from [..]/vendor/bundle/ruby/2.1.0/gems/dbox-0.8.2/lib/dbox/syncer.rb:85:in `saving_timestamp'
        from [..]/vendor/bundle/ruby/2.1.0/gems/dbox-0.8.2/lib/dbox/syncer.rb:93:in `saving_parent_timestamp'
        from [..]/vendor/bundle/ruby/2.1.0/gems/dbox-0.8.2/lib/dbox/syncer.rb:339:in `create_dir'
        from [..]/vendor/bundle/ruby/2.1.0/gems/dbox-0.8.2/lib/dbox/syncer.rb:192:in `block in execute'
        from [..]/vendor/bundle/ruby/2.1.0/gems/dbox-0.8.2/lib/dbox/syncer.rb:186:in `each'
        from [..]/vendor/bundle/ruby/2.1.0/gems/dbox-0.8.2/lib/dbox/syncer.rb:186:in `execute'
        from [..]/vendor/bundle/ruby/2.1.0/gems/dbox-0.8.2/lib/dbox/syncer.rb:15:in `clone'
        from [..]/vendor/bundle/ruby/2.1.0/gems/dbox-0.8.2/lib/dbox.rb:39:in `clone'

The folder Assets/hi/COVER doesn't exist but there is a folder named Assets/Hi/COVER.
If I execute the pull a second time, no changes will be aggregated.

Dear Author,
Your dbox is really a godsend for my use on the GNUroot debian chroot environment on Nexus 6p! It is so much better than other dropbox alternatives on ARM! Thank you for creating them!

As you know, dropbox api v1 is being turned off by June 2017. There does seem to be a Ruby client for dropbox API v2.
https://github.com/waits/dropbox-sdk-ruby
Is it possible to adapt dbox using v2 api? It would be a shame, not to mention great inconvenience, that the dbox no longer works next year!

Thank you for looking into this!
Regards
Jiang

Hi

sorry if get the terminology incorrect (and if this is my stupidity rather then and issue /bug)
but i am having an issue with dbox when i run the command-line version with no user loged in (System is an unattended RPI )

i have a small bash script that i run on occasion which does the command (the bash script is run from a python script )

the bash script is as below (with tokens removed) , it all works great as long as there is a user logged in via SSH if there is no user loged in then dbox it returns "[]"
is this a bug? or am i making a mistake in my usage? im open to suggestions

It does however need to be stated via the python script as that first starts up the modem/internet and checks its connected etc (its a mobile low power device)

!/bin/sh

DROPBOX_ACCESS_TOKEN=xxx DROPBOX_USER_ID=xxx dbox push /home/pi

also note python script is run as root on boot and when running the bash script uses the following
import subprocess
proc = subprocess.Popen(["/home/pi/job.sh"], stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
(out, err) = proc.communicate()
print "dbox output:", out
time.sleep(4)

Authorized the app as described in the readme, I tried to clone Public folder from my dropbox I get this error:
xbian@xbian ~ $ dbox clone Public[INFO] Encountered a dropbox error. Sleeping 3s and trying again. Error: #<DropboxError: Path '/Public' not found>[INFO] Headers: {"server"=>["nginx"], "date"=>["Tue, 03 Feb 2015 21:18:56 GMT"], "content-type"=>["application/json"], "transfer-encoding"=>["chunked"], "connection"=>["close"]}

This happens for every folder on my dropbox.
Any idea?

Hi Ken!

I think dbox 0.5.0 and 0.6.3 each introduced a memory leak. I wrote a test script to demonstrate, which repeatedly pushes and pulls and prints its memory use.

dbox 0.4.4: memory use grows very slowly, then appears to stop growing.
dbox 0.5.0: memory use grows fast, then slows down but doesn't appear to stop growing.
dbox 0.6.3: memory use grows much faster, but sometimes drops considerably, and may or may not be bounded.

Here's the test script:
https://gist.github.com/1963067

How to config DROPBOX_APP_KEY, DROPBOX_APP_SECRET, DROPBOX_AUTH_KEY, DROPBOX_AUTH_SECRET and how to I get DROPBOX_AUTH_KEY, DROPBOX_AUTH_SECRET