|
阅读：5743回复：31
[更新，python党的同步福音]被firefox强行合并的同步方式弄得烦死，求书签同步替代方案
最早我是用xmarks同步书签，但自从某次它弄丢了我一大堆书签后，我禁用了xmarks后回归了firefox原生同步的怀抱。
firefox以前版本的同步是可以选择用服务器端书签替换本地书签，或者反之的，新版并没有这种选项，而是强制对本地和服务器端书签进行合并。于是出现了问题。 我的firefox使用环境是这样的： 1、六百多条书签使用了多级书签文件夹管理； 2、因为各种各样的原因，我同时在使用许多不同的profile，每个都登录了firefox账号进行同步（有很多是通过克隆profile文件夹的方式创建的）； 3、大部分对书签的增删操作都发生在其中最常用的一个profile中，意味着其他profile的书签库基本都是过时的。 那么问题来了，一大一小两个： 1、在使用非常用profile时，firefox进行同步，本地过时的书签库会污染服务器端的书签，导致在使用常用profile同步时，已经被删掉的书签通过同步的方式回来了，这点勉强能忍； 2、不知道是firefox同步系统的bug还是什么原因，firefox的同步有时候会造成大量重复书签出现在本地书签库中，这些重复书签有的和原书签在同一个文件夹中，有的甚至破坏了文件夹结构，跑到别的书签文件夹去了…… 我原本的只有六百多条的书签在掺入了这些重复书签后达到了一千多条，而且搅乱了我原本的书签文件夹结构，简直是灾难！ 于是我网上找删除重复书签的方法，找到两个拓展：一个只能一条一条地删除书签，删四百多条书签要点一千多次，pass；另一个是没有选择性地删除所有重复书签，因为我要选择性保留位置正确的原本书签，也pass…… 没办法，只好自己动手，写了个python脚本解析书签备份的json，自动查找重复项，只保留添加时间最早的那条，导出修改后的json，firefox再选择从这个json中恢复备份。 好了，这下书签数量回归六百多条了，而且文件夹结构基本正确。 然而这远远不是安心的时候！过了几天我发现那些被我用脚本剔除的重复书签不知道什么时候居然又被同步回来了！ 真的恼火，难道我每隔一段时间就要来一次书签查重么？就没有办法让我重置服务器端的书签存储么？ 于是网上搜索，看到了两个相关的bugziilla： https://bugzilla.mozilla.org/show_bug.cgi?id=966530 这条是请求恢复以前同步系统的有向替换功能，但mozilla的人似乎并不想这么做，其中有人提到似乎改pref或者使用拓展可以实现改功能： wiki page explaining the prefs to flip, or an add-on that exposes them, for example 有谁知道相关pref或者wiki页面么？或者相关拓展？ 另一个bugzilla： https://bugzilla.mozilla.org/show_bug.cgi?id=812348 这条太长我没看完，不过它说明了有很多人遇到了和我一样的情况。 另外还查到了两个重置同步的偏方，一个是修改密码，这个我试了貌似没用； 另一个说是删除firefox账号，再用同样的邮箱注册……这个应该能见效，但是感觉略蠢我不大想用，不想以后每次需要重置同步的时候都重新搞一次账号啊。 于是，谁知道同步的相关pref，或者推荐一下能替代firefox原生书签同步的拓展？ ------------------------------------------------------ 2017-02-27 更新： 根据 https://dxr.mozilla.org/mozilla-central/source/services/sync/modules/engines/bookmarks.js#926 推测，只要你选择了恢复曾经备份的书签，firefox同步服务器的数据就会被清除并替换。 那么，据推测，目前的同步系统中单向同步书签可通过以下伎俩实现： 用本地数据替换服务器端数据 ： 打开书签管理窗口，选择备份书签，然后从刚备份的书签中恢复，再进行同步。 用服务器端数据替换本地数据： 删除profile文件夹下的places.sqlite（同时本地历史记录也会被删除），再进行同步。 注：如果profile文件夹中的bookmarkbackups子文件夹存有此前的书签备份，那么找不到places.sqlite的firefox会尝试从这些备份中恢复书签，所以，在删除places.sqlite后打开firefox前，请将bookmarkbackups文件夹删除、移走或者改名。确保firefox不会保留有此前书签的痕迹。 According to : https://dxr.mozilla.org/mozilla-central/source/services/sync/modules/engines/bookmarks.js#926 It seems that if you restore your previously backuped bookmarks, then all the bookmarks stored on the firefox sync server should be wiped and replaced by local ones. Here come tricks to implement unidirectional sync in current firefox sync system: Substitude local bookmarks for server bookmarks : show all bookmarks, backup bookmarks and restore from the file just backuped; then synchronise. Substitude server bookmarks for local bookmarks : remove places.sqlite locating in your firefox profile directory (local browsing history would be removed simultaneously), then synchronise. Note: if there are previous bookmark backup in 'bookmarkbackups' subdirectory within your profile directory, firefox which should fail to find 'places.sqlite' would try restoring bookmarks from those backup; so, after removing places.sqlite, it should be necessary to remove, move or rename 'bookmarkbackups' before opening firefox, to ensure no track of previous bookmarks remaining. ------------------------------------------------------ 2017-03-06 更新： @aaaa007cn 在26楼贴出了mozilla官方python版同步客户端的github： https://github.com/mozilla-services/syncclient 我大致看了下，好像可以实现对服务器端同步数据很细化的操作，不过目前无法解密获取的同步内容。 （03-06第二次更新： 还是热心的 @aaaa007cn 巨巨在28楼贴出了解密同步内容的方法： https://github.com/mozilla-services/syncclient/issues/30#issuecomment-280517782 将该段代码内容替换到syncclient/main.py中使用。需要注意，这是段python2代码，且需要额外安装pycrypto依赖。 另外，这段代码不支持在命令行指定要执行的命令，它默认只是从服务器获取同步的历史记录并解密，要获取解密的书签记录，请将代码中的 history 替换为 bookmarks 后执行。 ） 不谈论bug的话，现在唯一无解的似乎只剩下在手机端删除自电脑端同步来的书签文件夹这个问题了。 不过通过一系列很麻烦的步骤可以实现，在保持手机端其他数据的情况下，仅清除电脑端的同步书签： https://bugzilla.mozilla.org/show_bug.cgi?id=860107#c9 |
|
|
1楼#
发布于：2017-02-25 20:38
个人浅见:
原理: 主要的 profile\places.sqlite 设成 "唯读" 后可避免被更动, 然后才允许同步. 写批次档 *.BAT 将主要的 profile\places.sqlite 设成 "唯读", 然后 echo 某一行内容 >> profile\prefs.js 允许同步. 当要添加书签时须先禁止同步, 或跳出Firefox, 执行另一个 *.BAT echo 某一行内容 >> profile\prefs.js 先禁止同步, 再将主要的 profile\places.sqlite 设成 "可写入", 等添加书签后再执行 *.BAT 将主要的 profile\places.sqlite 设成 "唯读", 然后允许同步. ______________________________________________ Q.在设定同步下，能让两台电脑用不同的布景主题吗？ A. 法1.在网址列输入 about:config 搜 lightweightThemes.update.enabled 在上面按左键二次将 true 改设成 false 法2.如果是免安装版, 试将 下列两个档设为 "唯读" 看是否有效 \Firefox\DATA\profile\lightweighttheme-header \Firefox\DATA\profile\lightweighttheme-footer 免安装版( 此版 Flash Player 永不更新/不會被提示或警示 )请参考 : 狂奔的火狐! Firefox 52.0b9 免安装 异空版 Flash Player+26元件 (32/64位元可共用profile) ==> https://www.firefox.net.cn/read-52082 |
|
|
2楼#
发布于：2017-02-25 21:11
|
|
|
3楼#
发布于：2017-02-26 08:54
|
|
|
4楼#
发布于：2017-02-26 08:56
|
|
|
5楼#
发布于：2017-02-26 09:06
当然, 长久之计是使用者向发行者建议修正其缺失,
全球有众多的使用者, 难道大家都在默默忍受? |
|
|
6楼#
发布于：2017-02-26 09:30
火狐的书签同步就是 有这样的问题，所以换电脑我一般是打包配置文件整个备份。
|
|
|
7楼#
发布于：2017-02-26 13:22
tools241：当然, 长久之计是使用者向发行者建议修正其缺失,一直都有人在反馈相关的问题，我在搜索解决方案的时候找到一大堆 support.mozilla.org 的页面都说的是与我类似的问题。 主楼第一个bugzilla里面，他们已经承认了实现单向同步功能并不难，毕竟这是老版同步系统就有的特性，但他们就是要把这些功能对用户隐藏； 还有主楼我提到的第二个bugzilla，讲的差不多就是我遇到的重复书签问题，12年就被报告了到现在都没看到解决的苗头。 好像在mozilla那群人看来，有这种需求或者会遇到这种bug的人，只是用户中的极少数，而且他们觉得这些极少数人的需要是无关紧要甚至可以舍弃的。殊不知这些“极少数”才是firefox最忠实的用户。他们想和其他浏览器抢市场，拉拢那些大多数的墙头草用户，大概与之相比我这种小众用户的需求是可以被牺牲的。 也不知道到了firefox 57的时候我的拓展还剩几个能用。 等到firefox 完全向chrome看齐的时候，大概也就是我转投chrome的时候了。 |
|
|
8楼#
发布于：2017-02-26 14:52
myhead：一直都有人在反馈相关的问题，我在搜索解决方案的时候找到一大堆 support.mozilla.org 的页面都说的是与我类似的问题。mozilla与google相比，毕竟资金方面欠缺，而解决这些问题同样需要人力物力，当然就得考虑优先级，把资金用到何处才最实效。 个人认为并不是可以舍去，而是并不是无解。试试下面的扩展 https://addons.mozilla.org/en-us/firefox/addon/fvd-synchronizer/ 题外话，凡是同步都存在这样或那样的问题，chrome也不例外，而且这货就像屎一样，难用至极。firefox更崇尚的是制定性(freedom)，所以往往用户对其要求更加完美，更要求细节。高版本在每次关闭firefox后，配置文件夹内的bookmarks都会做即时更新，自己也可以偶尔手动备份一下该文件。还可以传到邮箱，走到哪都可以随时档回来。 |
|
|
9楼#
发布于：2017-02-26 19:00
skytalk：mozilla与google相比，毕竟资金方面欠缺，而解决这些问题同样需要人力物力，当然就得考虑优先级，把资金用到何处才最实效。其实一直以来我都是因为firefox的自由和可定制性而非它不用。 这个事例中最让我失望的也是这种自由的丧失。 能否设计出可靠的同步系统是做不做得到的问题； 而是否向用户开放单向同步的设置就完全是他们想不想做的问题了。 不可靠的同步系统加上不自由的同步设置，是做不到加上不想做共同导致了我在这个事例中糟糕的体验。 mozilla资源和能力有限，做不出足够可靠的同步系统，12年的bug至今无法解决，这我可以理解。 但从主楼列的第一个bugzilla(966530)中我发现，我所看重的用户自由和可定制性，对mozilla来说根本无关紧要，这是最让我失望的。 这不是第一个让我觉得mozilla有无脑精简、无脑向chrome看齐倾向的事例了。 前一段时间看到chrome取消更改页面编码的选项，我还在想chrome毕竟霸道，并且庆幸自己是firefox死忠。 现在我才悲哀地意识到firefox很有可能会和chrome走上同样的道路。 感谢推荐拓展，我装上试试。 其实我最想找到 https://bugzilla.mozilla.org/show_bug.cgi?id=966530#c21 里提到的能改变firefox同步方向的设置项或者拓展。 |
|
|
10楼#
发布于：2017-02-26 19:21
myhead：其实一直以来我都是因为firefox的自由和可定制性而非它不用。我感觉他的意思是，这个还没有、或许可以有。 有可能是：如果一小撮用户有完全控制同步行为的愿望，有其他方法解决该问题，例如一个wiki页面介绍首选项切换，或者一个附加组件接触它们，而不必改变Firefox本应有的行为（也就是标题所说的，将选项暴露给(所有)用户）。 c32说认为不应该向用户展示UI。c34与c32讨论后，认为当前方法可能是最少问题的。 重点还是同步出错的原因和解决方案（可能某些情况下有问题，而方案与测试未考虑到），如果只是提供选项由用户判断，可能治标不治本，而且判断失误率恐怕不低，尤其是普通用户，或者信息展现不充分时。并且，如果出错几率较高，可能反复要求判断。官方不加回判断选项，可能也在担心引入新的bug与复杂性，以及人力资源原因。 |
|
|
11楼#
发布于：2017-02-27 00:13
好贴，思考的很充分，楼主的感受也是我的感受
做不好的功能就该转成官方扩展 从一开始就没敢用同步，因为发现同步过程太不透明了，无法看到差异信息 Mozilla，你还不如架一个git服务器，用git同步算了 |
|
|
|
12楼#
发布于：2017-02-27 01:48
yfdyh000：我感觉他的意思是，这个还没有、或许可以有。其实对我有意义的一点只在于，几年后的今天世界上究竟是否存在这种pref或者拓展…… 我自认也算是个比较高级的用户了，只要是复杂度低于修改源码自己编译的方法都能接受，但现在的情况是不管我怎么搜索，结论全都是用户没有任何方法在这个同步系统中设置同步方向…… 然而在相当长的一段时间内恐怕都没有治本的可能。 同步会出错，mozilla那边的人都是知道的： https://bugzilla.mozilla.org/show_bug.cgi?id=812348#c48 开发同步系统的人都承认了现在的这个同步系统是有问题的，而问题的解决目前看来还是遥遥无期。 |
|
|
13楼#
发布于：2017-02-27 14:51
myhead：其实对我有意义的一点只在于，几年后的今天世界上究竟是否存在这种pref或者拓展……http://docs.services.mozilla.com/sync/lifeofasync.html#validate-meta-global https://dxr.mozilla.org/mozilla-central/search?q=_syncStartup 从文档和代码看，并未设计同步方向。 重点还是bug，理论上不应同步过期的数据。至于增加方向选项，恐怕遥遥无期。 |
|
|
14楼#
发布于：2017-02-27 16:09
yfdyh000：http://docs.services.mozilla.com/sync/lifeofasync.html#validate-meta-global等等！在第一个链接里粗略找了下代码，好像至少可以重置服务器端的数据啊？ https://dxr.mozilla.org/mozilla-central/search?q=needsWipe 然后是这里： https://dxr.mozilla.org/mozilla-central/source/services/sync/modules/engines/bookmarks.js#926 看起来选择从备份中恢复后就会自动重置服务器端的数据？ 那么我之前恢复备份后再次出现重复书签只有三种解释： 1、上面的代码并没有实际部署在我所用的版本中； 2、同步系统再次发生了bug； 3、在这个profile恢复备份后，我偶然间使用了另一个有问题的profile导致服务器端的数据再次被污染，并同步回了原profile。 最后一个的可能性最大，如果是这种情况的话我知道我该怎么做了： 首先，修改firefox同步账号的密码，确保我所有关联了这个的profile现在起不会自动同步；若要恢复某个profile的同步功能，先导入正确的书签备份，再输入新密码，恢复同步。 并且，如果以后有重置书签同步的需求，只需要导出备份再导入一次就可以了。 这样，只要那个会产生大量重复书签的恶性bug不出现，我的使用应该无虞了。 感谢指引，虽然bug隐患仍在，不过我的问题可以算是解决了。这帖应该可以给以后遇到类似问题的人留作参考。 |
|
上一页
下一页
