Notices


Reply
Thread Tools
Posts: 125 | Thanked: 108 times | Joined on Feb 2010
#31
thx for your help.

What I did:
1. on Server, created a test account (contains the usual demo files)
2. on Client (N900) I created /home/user/oc
(my real account uses /home/user/ownCloud)
3. I edited in .simple_oc.cfg the first three lines
to reflect the new username, password and directory

I called simple_oc
and it worked correctly

4. I put some files into the local documents subdir
and called again simple_oc
and it did correctly upload the new files to the server

ALL GOOD!
But the question remains: why not with my username/password/oc-dir?

Nevertheless thank you so much for helping me with this old little machine.
 

The Following User Says Thank You to rm53 For This Useful Post:
Posts: 125 | Thanked: 108 times | Joined on Feb 2010
#32
now I have changed back *only* my username and password in the config file - and again the same errors as before:
STATUS 301 "Protocol "" is unknown"
so it must be my username or my password?

=== later:

Now this becomes really odd,
because in some more experiments, I found out that my usual login-password is the problem. It contains an ASCII char which is neither alpha nor numeric nor control char. But: Changing the password to some plain alphanumeric string - all problems gone!

This is IMHO really strange, as with my original password I get that nasty 301 error only for the transfer of plain files, but not for transfering directory structure nor for initial login to the server!
The server login and the transfer/sync of the dir structure went okay. Only the files themselves produced that 301 error.
How can this be?

=> one vague idea: could it be that between
- simple_oc
and
- owncloudcmd
the password arg is not properly quoted?
But even if this were the case, it still remains the question why this only strikes for plain files, not for dir structure... mysterious.

Last edited by rm53; 2014-08-22 at 12:05.
 

The Following User Says Thank You to rm53 For This Useful Post:
Posts: 32 | Thanked: 77 times | Joined on Dec 2011
#33
I believe it is not a simple_oc error (checked the quoting and it seems ok). If the password contains an @ or /, then I don't know how this can be encoded in an url. You can check if your problem is due to owncloudcmd by directly calling it

Code:
owncloudcmd /home/user/oc https://user:pass@location
Where the location may or may not contain remote.php/webdav (both should work).

I once had a similar problem which is fixed in the current owncloudcmd: owncloudcmd seems to parse the input URL several times. My guess: one of the parsings is buggy, probably for storing the sync result in a database file. Since this fails, he undoes the sync but leaves the directories.

The whole "username@password in url" is ugly and will probably be fixed by me in the next version.
 

The Following 3 Users Say Thank You to hypnotoad123 For This Useful Post:
Posts: 562 | Thanked: 1,732 times | Joined on Jan 2010 @ NYC
#34
hypnotoad123, thanks so much for putting this together. It helped me a great deal.

I'm currently stuck on version 1.0-3, since newer version does seem to honor my blacklist .

Not sure how to fix it. I tried it on a back up device. Basically I have 3 folder, but only want 2 sync since one other has GB of info I don't need on my mobile.

Has anyone else run into this problem or know how to fix/trouble shoot it.

Thanks

x

p.s. fixing the "username@password in url" would be great (if I can get a new vera working)
 
Posts: 32 | Thanked: 77 times | Joined on Dec 2011
#35
Hi x,

did you blacklist directories or is a file blacklist not working? How did you do the blacklisting?

If you have multiple subdirs, just copy and modify simple_oc as follows: modify and multiply the owncloudcmd lines according to your needs

It should look like that (3 lines for 3 subdirs):

Code:
owncloudcmd dir1 https://$user:$password@hostname/owncloud/remote.php/webdav/dir1
owncloudcmd dir2 https://$user:$password@hostname/owncloud/remote.php/webdav/dir2
owncloudcmd dir3 https://$user:$password@hostname/owncloud/remote.php/webdav/dir3
Hypno

PS: Currently 1800 files in sync with 4.8gb in total take 5 seconds to sync (if there are no changes on both sides). This is faster than "df -h"!

Last edited by hypnotoad123; 2014-08-23 at 01:38.
 

The Following 3 Users Say Thank You to hypnotoad123 For This Useful Post:
Posts: 32 | Thanked: 77 times | Joined on Dec 2011
#36
Hi,

due to Poodle, server admins start disabling ssl3 which seems to be default in QT which in turn is used by owncloudcmd.

Nelisquare already fixed this, so I shamelessly took their patch and applied it for owncloudcmd. New version is approaching extras where it will be promoted as soon as possible.
 

The Following 7 Users Say Thank You to hypnotoad123 For This Useful Post:
Posts: 74 | Thanked: 45 times | Joined on Dec 2010
#37
I have just install and setup simple_oc
It works fine but inline and (.simple* ) options are failing. With this message:
xargs: invalid option -- 0

i wanted to use the --trust option, but it fails also with the default one (-- silent) that is in its config file.


reading the script i see options error and xarg does not seem to be related. In case there is a bug it would be here

. $cfgfile
[[ "$options"x == x ]] && options="--silent"
I only produce very simple shell script, someone can check that? otherwise i will try to check it in my computer

Last edited by antviro; 2015-02-01 at 11:43.
 
Posts: 74 | Thanked: 45 times | Joined on Dec 2010
#38
Originally Posted by antviro View Post
I have just install and setup simple_oc
It works fine but inline and (.simple* ) options are failing. With this message:
xargs: invalid option -- 0

i wanted to use the --trust option, but it fails also with the default one (-- silent) that is in its config file.


reading the script i see options error and xarg does not seem to be related. In case there is a bug it would be here



I only produce very simple shell scripts, someone can check that? otherwise i will try to check it in my computer
Just in case someone has the same error. In order to avoid the confirmation meanwhile being called from alarmed, i have run it together with yes application, with an script like that:
/usr/bin/yes | /usr/bin/simple_oc

I hopen I won't have any conflict, and in case, I hope they ask something different than a y/n question .

This is just a dirty cheat but seem to work meanwhile I don't have time to have a deeper look.
 
Posts: 32 | Thanked: 77 times | Joined on Dec 2011
#39
Hi Antviro,

there are at least two problems. The first is with xargs: Could you output the result of
Code:
which xargs
? I guess it is a version that does not understand the -0 argument.

Secondly about the options: Could you post the options line in the .simple_oc.cfg? I guess you did not add quotation marks like
Code:
options='--silent --trust'
Hypno
 
Posts: 74 | Thanked: 45 times | Joined on Dec 2010
#40
Originally Posted by hypnotoad123 View Post
Hi Antviro,

there are at least two problems. The first is with xargs: Could you output the result of
Code:
which xargs
? I guess it is a version that does not understand the -0 argument.
It is located in /usr/bin/xargs but I have seen it is just a simlink to busybox żż?? That is really strange, don't know which package has created that simb link.


Secondly about the options: Could you post the options line in the .simple_oc.cfg? I guess you did not add quotation marks like
Code:
options='--silent --trust'
Hypno
Now it is like that and trust is working. By the way by default it was written a
Code:
options=--silent
without quotation marks. I added them, but I was not using space as separation with trust.

Thanks.
 
Reply

Tags
cloud sync, maemo 5

Thread Tools

 
Forum Jump


All times are GMT. The time now is 09:57.