Hopkins
-
Posts
20 -
Joined
-
Last visited
Posts posted by Hopkins
-
-
I can confirm that this issue still happens for me with MS Access too. To test, set up a sync containing an Access database, open the database, then choose to compact it. Usually, on the first occasion, it just fails. If you persist them sometimes the process gets interrupted at a critical point and stranger things can happen. I have also had to resort to a backup before, although it's been a while. Now I make sure that I close sync before compacting
. -
No - I still have to quit BTSync, then compact my Access database, then re-open BTSync, otherwise it sometimes does weird things like abort half way through and even leave it in an unreadable state. BTSync is a great app that I'm willing to pay for when it is right, but at the moment the fact that this issue remains causes me not to recommend it to non-techies who might not be able to fix the problems it might cause.
-
Now it won't even connect for the backup over a lan... The Android version seems to have gone backwards!
-
I'm pretty sure that the old mobile version permitted the same operations as the desktop version. In fact, I specifically recall someone wanting a two way-sync of their photographs, and the response from a dev was to remove the default "backup" option and add the folder "normally". However, it seems as though adding a folder normally is no longer possible.
-
I would like the entire contents of my (android) phone's sim card to use a two-way sync with my PC. However, I cannot seem to do this. If I choose the backup option on the phone, I can create a share for my PC to connect to, but it is only read only on the PC. If I create an empty shared folder on my PC and attempt to point it to the mounted sim card on my android phone, it warns me that "Destination folder is not empty and files could be overwritten. Add anyway?", but then refuses to do this, repeatedly showing that message.
I cannot create a two way share on my phone and then add it to the PC.
Is what I am trying to do forbidden for some reason?
-
Hi,
I have a repeatable problem. After making some changes to a file (an Access database) which syncs with two other machines (another computer on the latest version, and a Synology box on 1.4.83), I noticed that the file was overwritten with an old version. I retrieved the deleted version from the archive and renamed it, overwriting the old file - but it was deleted again! So, I added a zipped version of the file to the directory in order to keep it safe. However, each time I extract it, deleting the wrong version, it is removed again. It is using the Synology (1.4.83) as the source.
Is there a secure address to which I can send my debugging log file?
Thanks.
-
RomanZ has already indicated what the change was.
Ah, apologies, I did not read that reply carefully enough!
-
This problem did not seem to exist with the earlier versions, e.g. 1.3.109 (which I still run on some machines just to avoid it). I assume that it is a side effect of some other change - I'd be interested (purely out of curiosity) to know what this change was.
-
Thanks for the info! I'll check the change-log before testing. It would be great if you could squeeze it in because it's the type of bug that might put off new users who are not able/prepared to get on to the forum and discuss problems - rather they'll uninstall the software and revert to an inferior third-party-server-based product!
-
Superb. I will notify you if it solves the similar problem I reported with MS Access.
-
GreatMarko sent me here after I made a similar report. A link to my post for reference: http://forum.bittorrent.com/topic/31881-file-locking-in-14/.
-
Ah, thanks, did skim through the titles before posting but didn't spot that. The process to re-create this error is
1) Open a database file in MS Access (I'm using 2010) in a BTSync shared folder with BTSync running
2) On another computer which is synchronised with BTSync running, open the equivalent MS Access database
3) Click on Database Tools -> Compact and Repair Database
4) Sometimes the compact succeeds, but sometimes there is an error. This error is usually "Could not use [path\file]; file already in use." However, occasionally it messes up the process completely and you get "Microsoft Access can't delete [path\file] after compacting it. The compacted database has been named [path]\Database.mdb."
I hope that this helps you isolate the problem! Whether or not the error happens seems a little strange. Sometimes you will get a run of half a dozen successful compacts, whereas other times you get a run of half a dozen failures. There is rarely a long sequence of success, failure, success, failure, etc., suggesting that some fluctuating external factors might be playing a part in determining whether the operation succeeds or fails.
-
I am trying v1.4 (1.4.83) for the first time. However, it seems to be locking files where previously it did not. Specifically, I am having problems with Microsoft Access compacting a database in a folder synchronised by BTSync. MS Access writes to a database file on opening, and it seems to "touch" the file in this manner before initiating the "compact" operation. However, after the touch, BTSync now seems to lock the file, causing the compact operation to fail (claiming that the file is already in use).
Closing BTSync, then compacting, then restarting the synchronisation is a (slightly inconvenient) work around, but this is not possible in some circumstances because BTSync may be running under a different user.
-
Can I assume from the lack of replies that this is way off-piste, and not at all in line with anyone else's thoughts on how BTSync should develop?
Re-reading it, perhaps my use of "Communication Code" is confusing. What I meant is that perhaps the one-time secret should be renamed to Communication Code in order to make it clear that it is designed for communicating, and to dispel the illusion that it is "just as secret" as the real secret!
The motivation for all this is that if I want to share a folder with someone, then the simple act of sharing it with them gives them the freedom to redistribute the secret (whether full access or read only) to anyone else. I lose control of who has access to the folder.
-
This type of behaviour might be possible if one time secrets did not reveal the "real" secrets. I made a more general post about this idea (http://forum.bittorrent.com/topic/30240-real-and-one-time-secrets/), and I am looking forward to hearing other users' and, hopefully, developers' thoughts. If you're going to do anything more than casual file sharing with BTSync then there must be more control over permissions an emphasis on "keeping secret" secrets!
-
That's an excellent idea, and not only for read-only secrets but also for one-time secrets too.
-
Many thanks for the replies. I will go through the feature requests as you suggest.
-
Integrating a the public key based "one-time secret" is a fantastic solution to the problem of the secure transmission of secrets. I also realise that it was added relatively recently to the product. However, in my opinion, BTSync should change to discourage the use of anything except a one-time secret for communication. Calling both the real and one-time secrets "secrets" implies that they are similar, but they are absolutely not. Losing control of a real secret is a complete disaster. Perhaps the one-time secret should even have a different name to reinforce that the actual secret is just that: it must, absolutely, remain a secret.
Imagine this alternative. Instead of seeing very easily the real secret of a folder, instead you are presented with the option to generate a "Communication Code". Before generating it, the user could specify whether the recipients can see or not see the real secret, how many times it can be used, how long before it times out and whether the recipient will have the permission to create new Communication Codes. The aim should be to avoid any requirement actually to use the real secret.
I realise that this is quite a major change, but since one of the strong points of BTSync is security, it would be a shame if it was difficult for non-techy users to understand how to use it securely.
-
Firstly, BitTorrent Sync is a fantastic product. Thank you!
Secondly, some questions for which I have not managed to find answers:
1) Is it possible to determine whether a one-time secret which was issued has been used?
2) Is it possible to hide the real secrets from users who are invited with a one-time secret, thus retaining control of who can share the folder?
3) Is it possible to see, for a given folder, how many different clients share that folder, including a split between full access and read only shares?
4) Is it possible to set the history to be persistent? Each time the client restarts the history list clears.
Thanks in advance for any replies.
.
Ms Office: Don't Have Permission To Write To The Selected Folder
in Sync Troubleshooting
Posted
Many thanks - I look forward to helping to test. I'm sorry that I did not respond to the last requests - they arrived at a particularly busy time and ended up getting buried in other issues which required my time.