Request for future: consider releases (with binaries)

[coxackie]

Really glad to see someone picking up development, and wish you best of luck in the future.

I see you have put more build dependencies (conan, for example) - in order to save the trouble for downloading a lot of make dependencies, I was wondering whether you would consider providing releases with binaries (maybe through github actions). That would make the installation much easier for a lot of folks. For one, I am the maintainer of the AUR package pcloudcc, and I would be happy to make a separate "bin" package (in time) from your binaries, if things progress.

Many thanks for your work!

[sergeyklay]

Hello @coxackie,

Of course, I plan to release binaries for different operating systems as well as provide support for easy package building (hello from Gentoo). However, I need some time to sort out some of the things that should go into the first release. According to an optimistic estimate, this is about a week or so, but I do not presume to say for sure. Thank you for the support and please let me know if you have any issue with this project.

[coxackie]

many thanks - sounds perfect!

I may suggest some ways to improve the client (by adding basic functionalities - of course, in separate issues), once you get in a "stable" state with the codebase the way you want it.

[sergeyklay]

Yes, of course! :)

[ChuckNorrison]

Hello and thanks for the fork, i will try to give some tests on this

[coxackie]

Yes, of course! :)

excellent, and really happy to see a lot of action here already. One preliminary request: there is at this point functionality from the electron pcloud app that is not possible to have with the console client (for example, selective sync). At least at this point, people (at least I, but I am sure a lot more) will still have to use the electron app sometimes to do something that the console client cannot do. Therefore, it is important to ensure that there is nothing in the console client's behaviour that may break functionality of the electron app.

[sergeyklay]

One preliminary request: there is at this point functionality from the electron pcloud app that is not possible to have with the console client (for example, selective sync). At least at this point, people (at least I, but I am sure a lot more) will still have to use the electron app sometimes to do something that the console client cannot do.

I'd like to get a list of all those features that are not available in the current version of the console client. Let's make a "New Feature Request" out of each such thing and I'll try to figure it out. I can't promise that these features will work out well (or that they will appears at all), however I'd like to try and at least have an exhaustive list.

Therefore, it is important to ensure that there is nothing in the console client's behaviour that may break functionality of the electron app.

It seems here I do not quite understand you. Of course, I make changes to the work of the client, as well as to its API. However, I don't quite understand how this might affect an Electron application that isn't based on the current version of the client. Could you please elaborate on that?

[coxackie]

It seems here I do not quite understand you. Of course, I make changes to the work of the client, as well as to its API. However, I don't quite understand how this might affect an Electron application that isn't based on the current version of the client. Could you please elaborate on that?

Sorry for not having been clear. I have not checked the codebase at all (just packaging, and actually using myself), so let me elaborate. When I want something like selective sync (local to cloud, etc), I will set it up through the electron app. Then, I will use the console-client running as daemon, and it will continue doing the selective sync that was set-up. (Feel free to test this.) I am not sure whether config files are read, or whether this is written in the database or whatever, but for some reason it works. What I am worried is that, if further functionality appears in the console client than it could break this "seamless" co-existence.

Again, as I have mentioned, I have not seen the codebase, so take what I am saying with a grain of salt.

[sergeyklay]

Then, I will use the console-client running as daemon, and it will continue doing the selective sync that was set-up. (Feel free to test this.)

Wow! I did not know :)

I am not sure whether config files are read, or whether this is written in the database or whatever, but for some reason it works.
I'm sure this is a database:

pcloud-console-client/src/psync/psettings.h

Lines 104 to 107 in 4214b5a

	#define PSYNC_DEFAULT_POSIX_DBNAME ".pclouddb"
	#define PSYNC_DEFAULT_WINDOWS_DBNAME "pcloud.db"
	#define PSYNC_DEFAULT_DB_NAME "data.db"

You can verify this using SQLite:

$ sqlite3 ~/.pcloud/data.db
SQLite version 3.35.5 2021-04-19 18:32:05
sqlite> .tables
baccountemail      filerevision       links              setting
baccountteam       folder             localfile          sharedfolder
bsharedfolder      fstask             localfileupload    sharerequest
contacts           fstaskdepend       localfolder        syncedfolder
cryptofilekey      fstaskfileid       myteams            syncfolder
cryptofolderkey    fstaskupload       pagecache          syncfolderdelayed
devices            fsxattr            pagecachetask      task
file               hashchecksum       resolver

sqlite> .header on
sqlite> .mode column

sqlite> pragma table_info('syncfolder');
cid  name       type           notnull  dflt_value  pk
---  ---------  -------------  -------  ----------  --
0    id         INTEGER        0                    1
1    folderid   INTEGER        0                    0
2    localpath  VARCHAR(4096)  0                    0
3    synctype   INTEGER        0                    0
4    flags      INTEGER        0                    0
5    inode      INTEGER        0                    0
6    deviceid   INTEGER        0                    0

sqlite> pragma table_info('syncfolderdelayed');
cid  name        type           notnull  dflt_value  pk
---  ----------  -------------  -------  ----------  --
0    id          INTEGER        0                    1
1    localpath   VARCHAR(4096)  0                    0
2    remotepath  VARCHAR(4096)  0                    0
3    synctype    INTEGER        0                    0

Could you check this using ususal SELECT ... FROM ... queries ?

Note, you should stop pcloudcc before interacting with the database. Otherwise you will get "Error: database is locked" response from the SQLite.

Until now, I have not made any changes to the database schema. And if I'm right regarding the config storage everything should work as before.

[coxackie]

yes, I guess it is this db file that does all the work. One may have to "reverse engineer" a bit what is going on. See the discussion here: pcloudcom/console-client#23 (especially towards the end). This may also give you some ideas on how to implement folder sync. Should I open a new issue for this?

[sergeyklay]

Yes, please open a new one :)

[sergeyklay]

@coxackie Since this was not a bug report or a new feature request, I transformed this into a discussion.

[sergeyklay]

@coxackie Just released first alpha version in 3x branch.

[coxackie]

@sergeyklay many thanks for the heads up! I guess binaries will start after the project exits alpha/beta?

[sergeyklay]

Yes, let me some time for this. I'll sort out with this too.