Grive is dead

146 views
Skip to first unread message

RFH

unread,
Mar 27, 2015, 12:33:10 PM3/27/15
to grive...@googlegroups.com
The latest source code is 0.2.

Somebody has been working on it, upgraded privately to 0.3 BUT the source code is not available anymore. It is only available as an RPM.

Next, there is a commercial application "based on grive!!".

The name is SyncDrive.

This smells fishy. I have nothing about going commercial but let's be honest and tell everybody that the Open Source grive is DEAD.

-RFH

Message has been deleted

peter.t...@gmail.com

unread,
Jun 4, 2015, 6:20:25 PM6/4/15
to grive...@googlegroups.com
On Friday, March 27, 2015 at 4:33:10 PM UTC, RFH wrote:
> The latest source code is 0.2.
>
> Somebody has been working on it, upgraded privately to 0.3 BUT the source code is not available anymore. It is only available as an RPM.

Grive 0.3 source code is available on github.

"git clone git://github.com/Grive/grive.git"

and read the README for instructions on updates.

On debian stable with gcc 4.9 I needed to make the following changes to get it to compile. The compiler screwily won't admit that long as an argument is the same as uint32_t. It doesn't find Json() declared with a long argument, but it does have it with a uint32_t arg, so just cast the darn thing and let's be done ... (compiler nuttiness leading to compiler barf cured by tap on the nose with cluebat).

--- a/libgrive/src/drive/State.cc
+++ b/libgrive/src/drive/State.cc
@@ -248,12 +248,12 @@ void State::Read( const fs::path& filename )
void State::Write( const fs::path& filename ) const
{
Json last_sync ;
- last_sync.Add( "sec", Json(m_last_sync.Sec() ) );
- last_sync.Add( "nsec", Json(m_last_sync.NanoSec() ) );
+ last_sync.Add( "sec", Json((uint32_t)m_last_sync.Sec() ) );
+ last_sync.Add( "nsec", Json((uint32_t)m_last_sync.NanoSec() ) );

Json result ;
result.Add( "last_sync", last_sync ) ;
- result.Add( "change_stamp", Json(m_cstamp) ) ;
+ result.Add( "change_stamp", Json((uint32_t)m_cstamp) ) ;

std::ofstream fs( filename.string().c_str() ) ;
fs << result ;


However, a few days ago Grive 0.2 stopped working, apparently because Google has changed their http responses. That's why I compiled Grive 0.3 (and why I upgraded to Debian stable in order to be able to). But it fails similarly:

Synchronizing folders
exception: /tmp/grive/libgrive/src/protocol/AuthAgent.cc(174): Throw in function long int gr::AuthAgent::CheckHttpResponse(long int, const string&, const gr::http::Header&)
Dynamic exception type: N5boost16exception_detail10clone_implIN2gr4http5ErrorEEE
[PN2gr4expt12BacktraceTagE] = #0 0x812612f grive gr::Exception::Exception()
#1 0x810acb6 grive gr::http::Error::Error()
#2 0x8110bad grive gr::AuthAgent::CheckHttpResponse(long, std::string const&, gr::http::Header const&)
#3 0x81106e5 grive gr::AuthAgent::Get(std::string const&, gr::DataStream*, gr::http::Header const&)
#4 0x80f4ab8 grive gr::v1::Drive::SyncFolders()
#5 0x80f502b grive gr::v1::Drive::DetectChanges()
#6 0x80dfcf3 grive Main(int, char**)
#7 0x80e0303 grive main
#8 0xb7012a63 /lib/i386-linux-gnu/i686/cmov/libc.so.6 __libc_start_main
#9 0x80deb11 grive

[PN2gr4http15HttpResponseTagE] = 400
[PN2gr4http6UrlTagE] = https://docs.google.com/feeds/default/private/full/-/folder?max-results=50&showroot=true
[PN2XXXX.iAHXXXXXXXXRD2SNjBWd8XXXXXXXXXXXXj
GData-Version: 3.0

so let's help the 0.3 guy solve the problem.

Fredd Oliveiras

unread,
Oct 15, 2015, 8:49:00 AM10/15/15
to grive-devel
I've been using this: https://github.com/vitalif/grive2
It works out.

vit...@yourcmc.ru

unread,
Oct 15, 2015, 10:10:44 AM10/15/15
to grive...@googlegroups.com
> I've been using this: https://github.com/vitalif/grive2
> It works out.

I confirm, this is my fork. It's alive and I'm even planning to
implement some new features :)

We also had a discussion in https://github.com/vitalif/grive2/issues/27
about that it would be good to take over the original "Grive" github
organisation...

But it seems there's no way to do it :-( GitHub said:

> I'm afraid I can't give you control of another GitHub account. We have
> a name squatting policy that sometimes allows us to release inactive
> usernames but the Grive account does not meet that criteria.

And the original authors don't reply.

If anyone knows how to contact them, I would appreciate this kind of
help :)

--
With best regards,
Vitaliy Filippov
Reply all
Reply to author
Forward
0 new messages