My OperaYou need to be logged in to post in the forums. If you do not have an account, please sign up first.
« Prev 1 2 3 4 5 6 7 8 ... 10 Next »
oSync - Opera profile synchronization / bookmark publisher
Hi, I would like you to test my new synchronization script for Opera, oSync.oSync is written in Python and uses the personal file space on my.opera.com to store files. It can be used to sync profile files between two computers, or always keep a HTML version of your bookmarks online, or both!
Screenshots/flyer: Link
Latest version:
http://sourceforge.net/projects/osync
Old versions:
oSync 0.5.0 (b141, Windows binaries)
oSync-0.5.0-b141_BIN.zip
oSync 0.5.0 (b141, Source dist)
oSync-0.5.0-b141_SRC.zip
oSync 0.5.0 (b139, Windows binaries)
Does not require Python. Recommended if you're running Windows and not interested in the source code.
oSync-0.5.0-b139_BIN.zip
oSync 0.5.0 (b139, Source dist)
oSync-0.5.0-b139_SRC.zip
Do require Python. Recommended if you're not running Windows or interested in the source code. This version, on Windows, opens a "DOS window" when running sync_windowed (unlike the Windows binaries).
Getting started guide (included above)
getting_started.pdf
Features:
- Synchronize any profile files through my.opera.com.
- Confirmed working on Windows and Linux.
- Compression, request caching, checksum and encryption support.
- File filters prevents synchronization of trivial changes.
- Very efficient network usage.
- Backups replaced local files.
Integrated as well as standalone tools:
- Bookmark file cleaner.
- Bookmark to html converter
New releases RSS-feed
This first post will be updated continuously (the posts right below this one are old ones).
Originally posted by van_grieg:
Originally posted by minisu:
Do you run any kind of firewall at all?
The built-in XP firewall, but I did try disabling it while testing. Same result.Are you running the source dist?
No, it's the binary.
I made a debug version for your problem:
oSync-0.4.2-DEBUG-b128_BIN.zip
This version should use no time out at all and includes a lot of extra libs (just in case). Please try it (anyone but van_grieg have no use for this version).
Preparing server... (might take a while) Writing files... Uploading files... Compressing files... Encrypting data... Wrote cache! Creating checksums... Skipped session filter! Traceback (most recent call last): File "setup.py", line 216, in ? File "misc.pyo", line 153, in uploadInstallData File "misc.pyo", line 85, in file2server File "urllib2.pyo", line 358, in open File "urllib2.pyo", line 376, in _open File "urllib2.pyo", line 337, in _call_chain File "urllib2.pyo", line 1021, in http_open File "urllib2.pyo", line 996, in do_open urllib2.URLError: <urlopen error (10060, 'Operation timed out')>
Originally posted by van_grieg:
The debug version still quits with a timeout...
Preparing server... (might take a while) [...] File "misc.pyo", line 153, in uploadInstallData [...] urllib2.URLError: <urlopen error (10060, 'Operation timed out')>
I've let some third parties examine the code and they all concluded that the code is correct.
As seen in the quote, the error occured when trying to upload another file than before. This time it managed to upload the data file (~74 kB in your case) but failed on the file oSync_install, which is just a few bytes. Also, you've not posted any errorlogs that indicates an error while downloading (which oSync setup always does before uploading).
Unfortunately, all this implies that the error is either somewhere between your computer and the my.opera.com servers or in the compilation
Please try this debug version (No compilation optimizing, setup loops until upload is done with success). This is all I can do at the moment.
oSync-0.5.0-DEBUG-b134_BIN.zip
(if this version don't work, there isn't a compilation error)
Others are recommended to wait until a binary release of 0.5
Originally posted by minisu:
Unfortunately, all this implies that the error is either somewhere between your computer and the my.opera.com servers or in the compilation
I'd say, fortunately.
In the meanwhile, I tried to run setup from another place, and it worked like a charm, even though there was a firewall there. Will try later tonight from home. my.opera.com didn't work well last night, so maybe there was something wrong on the server side. Thanks for your help!
I added a bookmark today and ran oSync. It uploaded osync_data, but failed to upload osync_meta again. After this, it refuses to work, immediately showing the "Something went wrong" message. Since I ran the program after the upload failed, the error.log got overwritten. It only shows this:
Traceback (most recent call last): File "sync_console.py", line 42, in ? File "urllib2.pyo", line 130, in urlopen File "urllib2.pyo", line 364, in open File "urllib2.pyo", line 471, in http_response File "urllib2.pyo", line 402, in error File "urllib2.pyo", line 337, in _call_chain File "urllib2.pyo", line 480, in http_error_default urllib2.HTTPError: HTTP Error 404: Not Found
I guess I can try to run setup again, but my question is: what if something goes wrong while uploading again?
7. November 2005, 20:25:03 (edited)
Originally posted by van_grieg:
Oops, it broke down again.
I added a bookmark today and ran oSync. It uploaded osync_data, but failed to upload osync_meta again. After this, it refuses to work, immediately showing the "Something went wrong" message. Since I ran the program after the upload failed, the error.log got overwritten. It only shows this:Traceback (most recent call last): File "sync_console.py", line 42, in ? File "urllib2.pyo", line 130, in urlopen File "urllib2.pyo", line 364, in open File "urllib2.pyo", line 471, in http_response File "urllib2.pyo", line 402, in error File "urllib2.pyo", line 337, in _call_chain File "urllib2.pyo", line 480, in http_error_default urllib2.HTTPError: HTTP Error 404: Not Found
I guess I can try to run setup again, but my question is: what if something goes wrong while uploading again?
So setup worked finally?
I assume you're running the 0.5 debug version? I only made retry-loops in setup - the sync binaries is the same as other versions.
I guess I better add retry loops for my upload function so that every upload gets looped. Maybe a timeout after a user editable amount of retries?
And ask for a feature request: encrypt the password, even if it's a 56bit encryption. I don't like clear passwords
Opera Mobile 11.10 on Android
Originally posted by minisu:
Maybe a timeout after a user editable amount of retries?
I think it's a good idea, but I'm more worried about consequences of upload failures. The program shouldn't be unable to work after one failure, I think. How about queuing operations on failures? (Please tell me when I start pushing too hard)
Originally posted by mmichel:
And ask for a feature request: encrypt the password, even if it's a 56bit encryption. I don't like clear passwords
You're right.
oSync-0.5.0-PREVIEW-b138_SRC.zip
WHAT'S NEW:
-Passwords are now encrypted.
* Using the computers hostname.
-Tweaked encryption algorithm
* 50% faster en/decryption.
-New default bookmark CSS.
9. November 2005, 17:39:59 (edited)
Originally posted by Nordlicht:
When can we exspect a oSync Version that runs
out of the zip without installing phython first?
I'm not sure what you mean...
You know that the zip labeled "Windows binaries" don't need a Python installation to run? The latest binaries are build 126, but if you want I can put up a binary version of the latest build.
13. November 2005, 12:24:11 (edited)
Originally posted by Nordlicht:
Is it possible to sync folders?
Or can I just sync files?
It would be nice to sycn the hole userJS folder.
So you can add a userJS at home and use it at the
office without editing the filelist.ini
You can only sync files at the moment. oSync is designed to minimize transfered data and therefore doesn't send a list of all synced files at each sync, just their hashes in a on beforehand decided order. This could be changed but unfortunately requires a major rewrite and time I don't have (now).
There are also one (at least) higher prioritized thing right now. That is to make oSync be able to upload files to the my.opera server without deleting the old file first. Currently, oSync has to do this at each upload (oSync usually uploads two files):
- Request to delete the file, wait for response.
- Get and parse response from above request.
- Confirm deletion of the file.
- Upload new file.
If there was just one way to upload files in replace mode (not necessarily accessible from the web interface), the above steps would turn into this single step:
- Upload new file.
Obviously, this would save a lot of time for users since most of the syncing time is not spent on actual transfers, but on response times. This would of course also save some bandwith for Opera, and it shouldn't (AFAIK) be such a hard thing to do for the server monkeys.
I have the code ready and I've PM:ed a server administrators about this during the week, but haven't got an answer yet, Which is kind of understandable since they can't be expected to change things just because one person thinks so.
So... if you think that this should be changed, please let me know in some way (replying to this thread, PM me or something)!
In the meantime, here's a new release (originally, the feature mentioned above was planned for 0.5.0, therefore this release don't differ much from 0.5.0 preview):
oSync 0.5.0 (b139, Windows binaries)
oSync-0.5.0-b139_BIN.zip
oSync 0.5.0 (b139, Source dist)
oSync-0.5.0-b139_SRC.zip
WHAT'S NEW (since 0.4.2):
-Added option to upload HTML version of bookmarks (see setup.ini)
* Usable at web cafés etc.
* Uses bookmarks.css for styling
* Can be used seperatly (use adr2html)
-Passwords are now encrypted.
* Using the computers hostname.
-Tweaked encryption algorithm
* 50% faster en/decryption.
-Removed a non-cross-platform (and unnecessary) module (thanks Gaau!)
-Updates getting_started.pdf
* Added "Tools" section.
* Added one client sync (read if you just want
to publish bookmarks without syncing)
-Added shutdown batch files in shortcuts/
-Cleaned up the directory/file structure
* All data files is now in data/ etc.
WHAT'S NEW (since 0.5.0 b138):
-Updates getting_started.pdf
* Added "Tools" section.
* Added one client sync (read if you just want
to publish bookmarks without syncing)
-Added shutdown batch files in shortcuts/
-Further cleanups of the file structure
Originally posted by minisu:
minisu --There are also one (at least) higher prioritized thing right now. That is to make oSync be able to upload files to the my.opera server without deleting the old file first. Currently, oSync has to do this at each upload (oSync usually uploads two files):
- Request to delete the file, wait for response.
- Get and parse response from above request.
- Confirm deletion of the file.
- Upload new file.
If there was just one way to upload files in replace mode (not necessarily accessible from the web interface), the above steps would turn into this single step:
- Upload new file.
Obviously, this would save a lot of time for users since most of the syncing time is not spent on actual transfers, but on response times. This would of course also save some bandwith for Opera, and it shouldn't (AFAIK) be such a hard thing to do for the server monkeys.
You are right that an upload-to-replace feature would benefit your project. But, regardless of whether or not you get that, you should be uploading to two different filenames in alternation. That is, if I do a push-sync, it uploads to "file1" on the server; if I immediately do a second push-sync, it should upload to "file2". Then back to file1.
Why? Because the data you're pushing could be precious. If an upload first erases the old version, there is a time window during which no versions exist on the server.
You may be thinking of this as just a convenience, but consider that in time it could become truly important to people. If they are synchronizing things like their bookmarks and notes, in some cases losing those could seriously affect someone's livelihood.
You may think: yeah, but if they're syncing, that implies they already have this stuff on at least two different machines! How important can the server copy be? However many machines someone has this data on, they are probably all physically close to each other. They might all be in New Orleans, for instance, and all get destroyed in 3 hours of hurricane fury. Meanwhile, the backup on Opera's server is 10000 miles away, safe and sound.
For a less exaggerated scenario, imagine I'm using my laptop in an airport, hooked up with wireless, running on battery. I've pushed things too far and the battery is about to expire. In preparing to sign off, I do a push-sync. My luck runs out, battery dies in the middle of the sync. Now there is no copy on the server. Later, I arrive at my parents to find that my laptop hard drive crashed in the power failure. I want to install Opera on their machine and pull-sync from Opera's server, but I can't.
Here's my point, speaking as a software engineer with 20+ years of experience working on software reliability: there are many possible sequences of unfortunate events in which the fact that you delete the copy on the server comes into play in a bad way. Each individual scenario is improbable. However, the probability that some (currently unanticipated) series of events will occur, and someone lose their data, is 100%. You can greatly reduce that probability by keeping two copies on the server and only deleting one when you're sure you have finished uploading the next.
The benefit is even higher if you really keep two copies on the server. (It's OK to blow away one of them while uploading the next update, as long as the other copy is continually intact.) A big benefit in this case is the ability to pull down both copies and compare them, e.g. to try to debug a situation where Opera has suddenly become unstable.
>Bela<
Originally posted by filbo:
You are right that an upload-to-replace feature would benefit your project. But, regardless of whether or not you get that, you should be uploading to two different filenames in alternation. That is, if I do a push-sync, it uploads to "file1" on the server; if I immediately do a second push-sync, it should upload to "file2". Then back to file1.
Why? Because the data you're pushing could be precious. If an upload first erases the old version, there is a time window during which no versions exist on the server.
You may be thinking of this as just a convenience, but consider that in time it could become truly important to people. If they are synchronizing things like their bookmarks and notes, in some cases losing those could seriously affect someone's livelihood. [...]
Thank you for your thoughts. This wouldn't be a hard thing to implement, but not a 5 minute hack either since all clients would of course always have to know which file to upload to.
However it's a good idea and I see no technical reason to not implement it. Don't hold your breath though.
>Bela<
Originally posted by filbo:
I actually don't see how to implement it without adding a server query to the steps. You need to know which of two names is currently newer, and by definition you don't already know (since the most recent upload might have been done from another machine).
oSync uploads two files; the actual profile data, which is encrypted, and a file containing meta data like checksums and clientname.
My idea is to add a switch in the meta file that alternates between 1 and 2 or something.
Originally posted by minisu:
I think an option page with the choice between "overwrite" and "increment file name" if file already exists is a better alternative.If there was just one way to upload files in replace mode (not necessarily accessible from the web interface), the above steps would turn into this single step:
You can still parse it, and Forum users will be able to overwrite data easily : updating files in my.opera storage should not be as a pain!
Opera Mobile 11.10 on Android
I'm trying to setup oSync to sync some files between my Windows and Linux installations, but it doesn't work. I managed to get it set up in Windows (with the binary version) and it uploaded files properly and all, but the src version in Linux keeps complaining.
When running 'python setup.py' it says:
oSync 0.5.0 (b139, Nov 11 2005) [src] Profile path found in setup.ini is invalid. Please edit setup.ini and restart setup. Press enter to quit...
I put oSync in a folder called osync in my home folder, and put ../.opera/ as the profile path in setup.ini. Shouldn't that be correct?
This is with oSync 0.5.0, Python 2.4.2 and Clientform 0.1.17 in Gentoo Linux (amd64).
Originally posted by Daedalus:
Hi.
I'm trying to setup oSync to sync some files between my Windows and Linux installations, but it doesn't work. I managed to get it set up in Windows (with the binary version) and it uploaded files properly and all, but the src version in Linux keeps complaining.
When running 'python setup.py' it says:oSync 0.5.0 (b139, Nov 11 2005) [src] Profile path found in setup.ini is invalid. Please edit setup.ini and restart setup. Press enter to quit...
I put oSync in a folder called osync in my home folder, and put ../.opera/ as the profile path in setup.ini. Shouldn't that be correct?
This is with oSync 0.5.0, Python 2.4.2 and Clientform 0.1.17 in Gentoo Linux (amd64).
Hej,
First, try go to opera:about to be really sure about your Opera directory.
If you're familiar with Python, try running the Python interpreter from the oSync directory and type the following:
>>> import os >>> os.getcwd()
This should return Pythons working directory. Now use
>>> os.chdir("PATH")
Use this as you normally use the "cd PATH" command, until the working dir is the oSync directory.
Once there type this:
>>> open("../.opera/opera6.adr")
If you get an error, this path is wrong and you have to think again.
Originally posted by minisu:
If you get an error, this path is wrong and you have to think again.
No error message as far as I can tell (I'm no python expert though).
>>> open("../.opera/opera6.adr")
<open file '../.opera/opera6.adr', mode 'r' at 0x2a955d3738>
Path appears to be correct. Setup.py still says it's invalid though.
I get the error message "something went wrong, see error log" when running "sync_windowed.exe".
This is the entry in the error log:
Exception called in module sync_windowed after 3334 ms.
(see info.txt for possible solutions)
Traceback (most recent call last):
File "sync_windowed.py", line 168, in ?
File "misc.pyo", line 61, in server2file
File "zipfile.pyo", line 210, in __init__
File "zipfile.pyo", line 230, in _GetContents
File "zipfile.pyo", line 242, in _RealGetContents
BadZipfile: File is not a zip file
I have followed the instructions in "Getting started" closely.
Originally posted by zombie:
I've not been able to get oSync to work for the last version.
I get the error message "something went wrong, see error log" when running "sync_windowed.exe".
This is the entry in the error log:Exception called in module sync_windowed after 3334 ms.
(see info.txt for possible solutions)
Traceback (most recent call last):
File "sync_windowed.py", line 168, in ?
File "misc.pyo", line 61, in server2file
File "zipfile.pyo", line 210, in __init__
File "zipfile.pyo", line 230, in _GetContents
File "zipfile.pyo", line 242, in _RealGetContents
BadZipfile: File is not a zip file
I have followed the instructions in "Getting started" closely.
How many clients? Which OS? Did you remember to run setup again after upgrading from an old version?
Which sync actions did you perform before this?
eg. "I first ran setup on client1, then on client2. Both was completed successfully. Then I synced on client1, blablal"
During setup I instructed oSync to overwrite entries on the server.
Setup went smoothly on both clients.
Running sync_windowed.exe gives me the before mentioned error on both clients.
Originally posted by Daedalus:
Originally posted by minisu:
If you get an error, this path is wrong and you have to think again.
No error message as far as I can tell (I'm no python expert though).>>> open("../.opera/opera6.adr") <open file '../.opera/opera6.adr', mode 'r' at 0x2a955d3738>
Path appears to be correct. Setup.py still says it's invalid though.
Try inserting these lines at line 59 (should be a blank line):
print "Working dir: " + os.getcwd() print "Profile path: " + PROFILE_PATH
Please run and post the result here.
Originally posted by zombie:
Two clients, both win XP. I deleted the old version before running setup again.
During setup I instructed oSync to overwrite entries on the server.
Setup went smoothly on both clients.
Running sync_windowed.exe gives me the before mentioned error on both clients.
Did the setup ask you which files you wanted to sync on the second client?
Originally posted by minisu:
Did the setup ask you which files you wanted to sync on the second client?
Yes it did. On the second client I chose to download the version on the server. Then the setup asked me which files I wanted to synchronize.
On my second client oSync is on a different drive than my profile folder. Could that be the problem ?
Previous versions of oSync could handle this.
Originally posted by minisu:
Please run and post the result here.
Done, results:
$ python setup.py oSync 0.5.0 (b139, Nov 11 2005) [src] Working dir: /da3dalus/osync /rofile path: Profile path found in setup.ini is invalid. Please edit setup.ini and restart setup. Press enter to quit...
Just to make sure I didn't screw up when editing setup.py, here's a screenshot of the edited file:
setup.py.png
Originally posted by Daedalus:
Originally posted by minisu:
Please run and post the result here.
Done, results:$ python setup.py oSync 0.5.0 (b139, Nov 11 2005) [src] Working dir: /da3dalus/osync /rofile path: Profile path found in setup.ini is invalid. Please edit setup.ini and restart setup. Press enter to quit...
Just to make sure I didn't screw up when editing setup.py, here's a screenshot of the edited file:
ATACH]
Hmm... The only thing I can think of is that you've accidentally written some spaces/tabs or other non-visible characters in setup.ini. This could make oSync interpret these characters as the profile path (and will be fixed in next release).
Originally posted by minisu:
The only thing I can think of is that you've accidentally written some spaces/tabs or other non-visible characters in setup.ini. This could make oSync interpret these characters as the profile path (and will be fixed in next release).
Hmmm... do line breaks count? I typed in the path manually, so I'm quite sure there are no tabs or spaces before or after the path.
Based on that info, I tried removing all line breaks before and immediately after the line with the profile path (previously I had left all line breaks that were in the original file, the only thing I changed was the path). So now the relevant part of setup.ini is:
################################################# ######################### ### Profile directory ### ../.opera/ ###################### ### Bookmarks HTML ###
It seems to have had some effect, as setup.py now says:
$ python setup.py oSync 0.5.0 (b139, Nov 11 2005) [src] Working dir: /da3dalus/osync /rofile path: ../.opera/ Profile path found in setup.ini is invalid. Please edit setup.ini and restart setup. Press enter to quit...
At least the line isn't blank anymore
19. November 2005, 21:06:39 (edited)
Originally posted by zombie:
Originally posted by minisu:
Did the setup ask you which files you wanted to sync on the second client?
Yes it did. On the second client I chose to download the version on the server. Then the setup asked me which files I wanted to synchronize.
That's the problem! oSync should not ask you which files that you want to synchronize when joining another session. Which files that should be synced are static for a session and is decided by client1.
When setup does this anyway, it's becuase something went wrong. In most cases, oSync will crash and display a traceback when something goes wrong, but not in this part of setup becuase of some badly written error catching code. This will hopefully be fixed in the next release.
For now, please rerun setup on client1 and use this modified version of setup for client2 that'll crash and show error info. I will edit this post and attach the modified version once you tell me if you're running the binary or source version on client2.
Originally posted by Daedalus:
Hmmm... do line breaks count? I typed in the path manually, so I'm quite sure there are no tabs or spaces before or after the path.
Based on that info, I tried removing all line breaks before and immediately after the line with the profile path (previously I had left all line breaks that were in the original file, the only thing I changed was the path). It seems to have had some effect, as setup.py now says:$ python setup.py oSync 0.5.0 (b139, Nov 11 2005) [src] Working dir: /da3dalus/osync /rofile path: ../.opera/ Profile path found in setup.ini is invalid. Please edit setup.ini and restart setup. Press enter to quit...
At least the line isn't blank anymore
No, line breaks (empty lines) doesn't count. What I meant was other line that just contains one or several spaces/tabs, which you've seem to get rid of however
My last idea is to write the absolute path instead. I have no idea if it works at all, but it could be worth a try. In case the result don't differ, I'm unfortunately out of ideas for now and I ask other Linux/oSync users to help if they can.
Originally posted by Daedalus:
Notice how the "Profile path" message is corrupted. It looks like a carriage return came after "../.opera/".setup.py now says:
$ python setup.py oSync 0.5.0 (b139, Nov 11 2005) [src] Working dir: /da3dalus/osync /rofile path: ../.opera/ Profile path found in setup.ini is invalid.
Does oSync make any attempt to deal with the two common end-of-line styles: "line1<CR><LF>line2" vs. "line1<LF>line2"? I would guess Daedalus's opera6.ini has CRLF line terminators, or possibly a mix of CRLF and LF.
Daedalus: try removing all <CR> (hex 0D) characters from your opera6.ini, leaving only <LF>. There are many many ways to do this. One is:
mv opera6.ini opera6.ini.bad tr -d '\r' < opera6.ini.bad > opera6.iniminisu: oSync should probably ignore all CR (0D, '\r') characters in input lines. Or at least any CR at the beginning or end of the line. It is not sufficient to try to determine the file's end-of-line style when you first open it, because you will often see files with mixed CRLF and LF line terminators. Many editors and programs like Opera don't care; you need to match that.
>Bela<
Originally posted by filbo:
minisu: oSync should probably ignore all CR (0D, '\r') characters in input lines. Or at least any CR at the beginning or end of the line. It is not sufficient to try to determine the file's end-of-line style when you first open it, because you will often see files with mixed CRLF and LF line terminators. Many editors and programs like Opera don't care; you need to match that.
Thanks, you're absolutely right! I've fixed this now.
oSync 0.5.0 (b140, Source dist)
oSync-0.5.0-b140_SRC.zip
WHAT'S NEW: -Now ignores Carriage returns, initial tabs and spaces (thanks filbo!). -Minor fix to (profile) path standardizer.
Originally posted by minisu:
For now, please rerun setup on client1 and use this modified version of setup for client2 that'll crash and show error info. I will edit this post and attach the modified version once you tell me if you're running the binary or source version on client2.
I'm running the binary version on both clients.
Thanks.
Originally posted by Daedalus:
Well, I tried the new build. I removed all previous oSync files, extracted the new files, edited setup.ini, and tried python setup.ini, but it came back with the same error as the older build.
Then I tried the mv and tr commands from filbo, and it worked perfectly.
Glad to hear it finally worked out. It seems like my hotfix was a little to hot.
I will look more into that tomorrow...Originally posted by zombie:
Originally posted by minisu:
For now, please rerun setup on client1 and use this modified version of setup for client2 that'll crash and show error info. I will edit this post and attach the modified version once you tell me if you're running the binary or source version on client2.
I'm running the binary version on both clients.
Thanks.
No problem, here you go... (remember, only for client2)
setup.exe
Originally posted by Daedalus:
Well, I tried the new build. I removed all previous oSync files, extracted the new files, edited setup.ini, and tried python setup.ini, but it came back with the same error as the older build.
Then I tried the mv and tr commands from filbo, and it worked perfectly.
Great! Would you like to send me your config file so that I can ensure that I've fixed this problem this time?
zombie: I'm online at irc.opera.com if you have the time...
22. November 2005, 14:21:24 (edited)
Originally posted by minisu:
Great! Would you like to send me your config file so that I can ensure that I've fixed this problem this time?
Sent in PM
Edit: I just noticed I now have my bookmarks as an html file here. Very odd, since I did not enable that feature, and it was not included on the first syncs. It was uploaded when I synced in Windows after setting up osync in Linux. How did that get turned on?
Originally posted by Daedalus:
Originally posted by minisu:
Great! Would you like to send me your config file so that I can ensure that I've fixed this problem this time?
Sent in PM
Thanks!
Unfortunately, I still don't know why it doesn't work for you with the bad setup.ini you sent. It works here.
I'm thinking of switching to Pythons built in config-parsing system in the future, to avoid problems like these.
Originally posted by Daedalus:
Edit: I just noticed I now have my bookmarks as an html file here. Very odd, since I did not enable that feature, and it was not included on the first syncs. It was uploaded when I synced in Windows after setting up osync in Linux. How did that get turned on?
Are you really sure it wasn't included in the first syncs? oSync only reads setup.ini when running the setup.
Other random hints:
It was enabled by default in the first 0.5.0 preview (build 132).
If you want to be sure that your bookmarks won't be published again, simply remove adr2html (.py/.exe).
Originally posted by minisu:
Are you really sure it wasn't included in the first syncs? oSync only reads setup.ini when running the setup.
Other random hints:
It was enabled by default in the first 0.5.0 preview (build 132).
If you want to be sure that your bookmarks won't be published again, simply remove adr2html (.py/.exe).
Yes, I'm quite sure of it. After setting up both clients I had the oSync_data/meta/install files. After syncing again in Windows it uploaded the html bookmarks. And I know the line about uploading bookmarks in setup.ini said 0 (it was set to 0 from the beginning and I didn't change it).
I didn't try the preview (or any previous version).
Is the fifth line (between the path and html bookmarks name) in settings.ini about html bookmarks? It is 0 there as well.
Since it keeps uploading the html, I've taken the hint and removed adr2html now.
When I tried syncing a few minutes ago, it came back with a 404 error, saying oSync_data couldn't be found. I looked at my files, and for some unknown reason I now had a file called 1oSync_data instead of oSync_data. So I downloaded 1oSync_data, renamed it to oSync_data and uploaded it manually, and after that oSync downloaded it and synced fine. I'm not really sure what's gonna happen next time I upload changes with oSync, though.
Originally posted by Daedalus:
Does oSync ever rename it's own files on the server?
When I tried syncing a few minutes ago, it came back with a 404 error, saying oSync_data couldn't be found. I looked at my files, and for some unknown reason I now had a file called 1oSync_data instead of oSync_data. So I downloaded 1oSync_data, renamed it to oSync_data and uploaded it manually, and after that oSync downloaded it and synced fine. I'm not really sure what's gonna happen next time I upload changes with oSync, though.
I'm sorry to hear that.
This have happended to me a couple of times and I feel pretty safe to claim that this is related to a problem mentioned before: The my.opera.com servers renames a uploaded file "foo.bar" to "1foo.bar", "2foo.bar" and so on if the file "foo.bar" already exists. There is no way to upload and replace files.
This is a huge problem for oSync as it causes problems and confusion when temporary network errors/delays occurs (as in your case) and more than doubles the upload time since oSync have to "click itself" through a delete-confirmDelete-uploadNew sequence instead of just uploading and replacing old files. But most of all, it lowers my motivation on updating and improving oSync.
I've proposed an option to replace uploaded files to the server admins about a month ago but they had higher prioritized things to do then. Of course that totally depends on how many users that wants this. I encourage all oSync users to let the admins know if you want this replace-when-uploading thingy, it would probably be enough if you just replied to this thread[/b]
Originally posted by minisu:
+1I encourage all oSync users to let the admins know if you want this replace-when-uploading thingy, it would probably be enough if you just replied to this thread
I was upset when updating files like a published CSS, or so. Any update is a pain. I don't think replacing is so dangerous they set the autorename feature.
Opera Mobile 11.10 on Android
Originally posted by minisu:
The my.opera.com servers renames a uploaded file "foo.bar" to "1foo.bar", "2foo.bar" and so on if the file "foo.bar" already exists. There is no way to upload and replace files.
Ah, so that's what caused it.
+1 on adding a update/replace file feature, would be very nice to have.
15. December 2005, 22:05:44 (edited)
Preparing server... (might take a while)
Traceback (most recent call last):
File "setup.py", line 191, in ?
File "misc.pyo", line 131, in getCookie
File "urllib2.pyo", line 130, in urlopen
File "urllib2.pyo", line 364, in open
File "urllib2.pyo", line 471, in http_response
File "urllib2.pyo", line 396, in error
File "urllib2.pyo", line 337, in _call_chain
File "urllib2.pyo", line 554, in http_error_302
File "urllib2.pyo", line 364, in open
File "urllib2.pyo", line 471, in http_response
File "urllib2.pyo", line 402, in error
File "urllib2.pyo", line 337, in _call_chain
File "urllib2.pyo", line 480, in http_error_default
urllib2.HTTPError: HTTP Error 404: Not Found
Another had posted a similar error but i'm not sure that an answer was ever posted in response. Any suggestions would be helpful! Thanks.
« Prev 1 2 3 4 5 6 7 8 ... 10 Next »
Showing topic replies 151 - 200 of 498.