Skip to content

Release v0.2.8(Eureka!)
Compare
Choose a tag to compare
@odeke-em odeke-em released this 12 Aug 08:13
· 333 commits to master since this release
v0.2.8
663ecf0

This release features numerous bugs fixed and a couple of enhancements:

  • parallelized uploads:
    a) This was requested directly by @Queatz in issue #315.
    b) As a remedy to the high target issue #77 reported by @jpambrun, as well as a duplicate issue #158 raised by @sohamm17. Basically what was happening was that if deeply nested folders were encountered, due to the previous sequential uploading behaviour moreover every push required a naive remoteMkdirAll call, the time spent eventually built up. This issue was solved by a combination of an introduction of a cache, plus fix for remoteMkdirAll as well parallel uploads. This was fixed in PR #318.

  • added exponential backoff retry mechanism: This was requested in issue #320 and addressed by PR #321. It allows for retrying of uploading on encountering some retryable e.g userRateLimitExceededError, InternalServerError.

  • retry on OAuth errors: This was reported in issue #326 and addressed by PRs #326 and #327.

  • fixed .driveignore for subfolders/children: This issue was reported by @twstdpear in issue #328. What happened was that the ignorePattern checks were not being made for subfolders/children. This was fixed by PR #336.

  • fixed up duplicate directory creation: This issue was reported by @vaiby in #186. Basically what was happening was a race condition to create folders on Google Drive which allows for multiple folders different ids, although your file system ordinarily won't allow for this. A simple scenario to replicate this would be to have two routines r1, r2. r1 -> /test/t1/content.txt, r2 -> /test/t1/content.txt. r1, r2 when both dispatched at time t go through the remoteMkdirAll call and even with latency Google Drive will return that the dirs do not exist and each one of these routines will create their own folders with the exact same names/paths.
    The remedy was to serialize and memoize remoteMkdirAll calls with the introduction of an expirable cache. This was fixed by PR #318.

  • fixed up pull goroutine rationer to match new pattern: This issue was reported in #332 and addressed by PR #333. It allows for simpler control.

  • Introduction of a verbose option for pull/push: This was introduced in PR #333. It allows for the user to see the on-going operations.

  • removed excessive memory consuming golang/text/collate during build: This was reported in issue #330. This was a show stopper because users on devices with low memory couldn't build drive. Plain string sorting was the remedy at least for now until golang/text/collate is working alright and not consuming a lot of memory. This issue was fixed in PR #331.

  • reverted using of multiple drive sessions: This issue was reported in #337. It was caused by the creation of a DB session to allow for multiple goroutines to write to the DB. However because the DB being used BoltDB locks the DB file, from the time that .Open() is invoked until .Close() is invoked, this meant that no other drive session could access the DB. This issue was fixed by PR #339.

    This release has been a long time coming because it solves a whole lot of issues that were show stoppers. Now, drive uses as much concurrency as can be limited during pushes and pulls. This makes uploading/downloading a whole lot faster; the retry mechanism for errors allows for efficient retrying instead of dropping of files on encountering the first error, it also allows for proper uploading and more control. drive feels a lot more reliable and efficient -- qualities that users can hopefully rely on.

Assets 2
Loading