The Dave

  • Content Count

  • Joined

  • Last visited

Everything posted by The Dave

  1. This is intended behaviour on folders I need to actually sync. Unless I can set this per folder? Even so, it doesn't solve the problem, now I need to delete photos from at least three places.
  2. Right Helen, that's the problem. If I take a bad or inappropriate photo, I literally can't delete it. If I delete it from my desktop, the copy on my laptop replaces it. If I delete it from my laptop, the copy on my desktop replaces it. This makes the feature basically useless. What I personally would like would be a true two-way sync. Keep my sync folder in complete sync with what is on the device's photos. This still functions as a backup due to Sync's archive feature. But even if that's too much effort, at least allowing me to make the folder read-write so that I can delete unwanted content would be a start.
  3. You can't delete photos. My assumption is that whoever designed this feature doesn't actually use it because it's just silly as-is.
  4. I'm not worried about accidental deletions though, both iOS and Sync keep deleted files for 30 days. What I need is an offsite backup, in case I lose my device. When I delete something from iOS, is it supposed to delete from the Sync folder? That would be great if it did, but it doesn't seem to happen.
  5. This is only part of the story, virtually all modern operating systems will attempt to avoid fragmentation when applications pre-allocate files with the appropriate sizes. However, if an application creates a bunch of tiny files and then appends data to them (without pre-allocating), you'll end up with substantial fragmentation as the file system was optimizing placement for small files. This frequently happens with log files, which by their nature, don't have a size that can be known in advance, but for applications which know the size of the file when it starts, an application developer can greatly reduce fragmentation (and in some cases, increase write performance) by pre-allocating files. (Why would this increase write performance? Because in some cases, file systems need to zero space before it can be used, if you pre-allocate the entire file, the file system will zero using a low-priority task whereas if you append to a file, it needs to be zeroed just a few blocks ahead of the write. Again, file systems try to optimize by completing your write and then zeroing the remainder of the block, but if the block size you're writing doesn't match the file system, you'll end up with weird effects) Now to be clear, I have not looked at how Sync creates large files, whether it pre-allocates files or not, but my point is that the application layer is a major factor, not just the file system.
  6. Awesome, thank you! I appreciate it and I'll keep this in mind and do the upgrades carefully!
  7. Any details on when this is likely to happen or why? Will the situation be handled better by the next build, or is this a potential issue no matter what? To clarify, I'm not annoyed/update/whatever, I just have a few non-technical users now, I believe all are running 2.3.3, they will definitely not backup their storage folder properly. If 2.3.7+ will dodge the issue, I'll wait it out, but if it's a bug that can't be resolved without taking the one-time risk of the storage folder getting lost, I'd rather "rip off the bandaid" and upgrade everyone by hand this weekend to take advantage of the memory leak fixes.
  8. Sure, I realize that they were never endorsed, but I'm still curious what happened -- Was the business model not sustainable? Or were their technical problems or reasons why it doesn't work?
  9. I'm testing the Camera backup feature on iOS, how does one delete a "backed up" image? My dream feature would be to have my iOS Camera Roll replicated in a Sync folder so that changes are replicated to my computer in real time (within the limits of iOS backgrounding, of course -- Assume I open the iOS Sync app and let it sync), if I delete something from iOS, I want it deleted on the desktop as well, and vice versa, it would be useful to be able to clean up from the desktop and have the photos deleted from the iOS photo library on the next sync. However, since a true sync doesn't seem to be possible, is there at least a way to delete some of the photos once I've saved them to their permanent home?
  10. Ahh, so it's LAN discovery that is part of what allows peers to share information about other peers? Fair enough. This will give me a workaround when I'm roaming. Would it be possible to request a feature to add an advanced option that would control whether my client will "Accept information from peers about other peers"? -- In other words, I'd like to discover people on the same LAN using broadcasts (I believe this is how Sync does it?), but otherwise, only use pre-defined hosts (our publicly accessible, high bandwidth server) The point about cached peers is noted and appreciated. Thanks!
  11. The desktop edition. Limiting the bandwidth rate doesn't really help, even small numbers are enough to run up a significant bill when carriers are charging roaming overages of $1/MB or more (20Kb/s is 72MB in a work day, which is both a trivially small amount of data if you're actually working, a large bill if you hit overages). My parents pay $5/MB. What I'm looking for is a mode to act like a leech rather than a full peer, upload only the bare minimum (local changes, and then only once), let the rest of the peers exchange amongst themselves. Obviously if everyone in a peer-to-peer environment used this approach, it would defeat the purpose, but if people used it responsibly and appropriately, it could save significant money for roaming users while still allowing them to keep up with changes.
  12. See if this helps explain? B - A normal folder, I have RO access only. I can toggle "Overwrite" if I want. This is good. E - An encrypted folder, I have RO access only. I can't toggle "Overwrite". Why not? F - An encrypted folder, I have Encrypted access only. "Overwrite" is locked on as you described, this is expected and good.
  13. At this point I'm less confident about this solution. I haven't had as much time to test as I hoped, but it looks like the peers still eventually find each other even if I turn off "Use tracker server", although it doesn't happen as quickly. However, some of the peers appear greyed out, I'm not sure what that means either.
  14. Sorry, I wasn't clear -- I'm using an RO key, not an encrypted key, so I have read-only access to the files. This works as expected on my peers that use the encrypted version of the key (and I agree, it should be mandatory there) However, it only happens on a folder that has encryption enabled, if I create a standard read-only folder, I can enable the "Overwrite any changed files" switch if I want.
  15. It looks like and are both dead, any chance either of the authors could comment on what happened? Was it a licensing issue, or something else? Rolling my own from any random VPS using encrypted folders isn't difficult, but I don't really want to take responsibility for other's data, so I was hoping for a solution I could offer to less technical users.
  16. I'm running into a case where "Overwrite any changed files" is unavailable. It works fine for Normal folders when a Read Only peer joins, but in an Encrypted folder when a Read-only peer joins, this option is unavailable. The mouseover text reads "This option does not apply because of your folder permissions" (but when I View key, I only see Read Only and Encrypted, so I definitely do not have Read Write permission) Any idea why? It seems like the option should be available whether or not encryption is used.
  17. I'd like to request a bandwidth-lite mode, which when enabled, would cause a Sync client to transfer blocks as conservatively as possible, assuming that each byte transferred has a cost associated with it. This would cause Lite mode peers to avoid uploading blocks when there are Normal peers that have the same block available. Roughly similar in concept (but not implementation) to BitTorrent's "Superseed" mode, however, one can assume Sync clients are generally cooperative, there is no need to wait to see other Normal peers uploading blocks before sending subsequent blocks. Rather, the goal would be for a Lite peer to selectively send blocks as few times as possible (idly only once), and only to the best peers to replicate the blocks out again. If all clients with a block are in Lite mode, they would operate the same as today, but the idea is to let the Normal clients take on more of the burden when there is a mix of lite and normal peers together. The use case is when you have a mixture of metered and unmetered peers coexisting (for example, laptops on mobile connections compared to workstations or servers on wired/unlimited connections), a mobile connection should still be able to add/modify files and receive changes and otherwise stay up to date, but should be as conservative as possible on the number of bytes transferred. Ideally this would be enabled/disabled with a single toggle similar to the Pause toggle (or possibly a three-way switch? Pause/Lite/Normal), with an advanced option controlling whether it applies to LAN peers or not. For example, if I have two laptops on a single LTE connected wifi personal hotspot device, traffic between the devices is "free" and should flow normally, while these peers should naturally avoid transmitting blocks to remote Sync peers more than once (and instead optimize to allow the remote peers to exchange blocks among themselves) In addition to conserving bandwidth, this would also help stretch battery life as transmitting blocks has a non-zero battery cost. It might be worth considering a pair of automatic switches as well, "Switch to Lite mode when on Battery" and "Switch to Lite mode when on metered connection (Windows 10)"
  18. I'm currently testing Sync on a small scale environment, for an eventual deployment on a larger scale. One concern I have is bandwidth consumed by mobile users who are paying per byte transferred, and have a need to sync files. My initial testbed was a pair of local servers (S1, S2), and workstations (W1, W2, W3), all of which are on the same wired LAN. I don't care about bandwidth consumption here, and the synchronization works perfectly. I was also planning on adding a remote server, VPS1, and am in the process of provisioning such. VPS1 will only carry the encrypted versions of files for security/safety, but will be on a multi-GB/s internet connection. In initial testing, if I write 1GB of data to Sync on W1, I only see around 1GB of data go out to VPS1, which is expected and perfect. However, W3 is a laptop and when it's on a 3G/LTE connection (therefore outside the LAN), and I place a 100MB file into a Sync'd directory, I saw at least 200MB worth of bandwidth consumed. My idea about how to fix this is as follows: On the workstations, I will uncheck "Use tracker server", but leave "Search LAN" checked. I will then also use "Use predefined hosts" and list VPS1. If I've understood the logic, Sync will use "Search LAN" to discover local clients, but once machines move out of broadcast range, files will synchronize to VPS1 and it will take care of synchronizing the files out to other users, defeating the peer-to-peer beauty and therefore reducing bandwidth consumption. Does this approach make sense? Will it work? Is there a better approach?
  19. Indeed. I'd like to set the rescan value very high as well, to reduce power consumption on a laptop. I can rely on change notifications most of the time, but the odd time when I have made a change that won't be notified properly (e.g. fixing NTFS permissions), I'd like to be able to do something about it.
  20. I've been testing Boxcryptor, which fits the bill nicely. I've previously used it with Dropbox and other solutions, and it works well enough with Sync as well. I use Boxcryptor Classic, which creates a virtual drive, encrypts the files and stores them on your normal filesystem. Since they're seen as encrypted files, everything filesystem level "just works", while applications use the virtual drive and sees unencrypted files as normal files too. In the context of Sync, you synchronize the encrypted .bc folder. The only catch is that Selective Sync doesn't work (or at least, would be very painful to manage, as you'd have to manage the files from one place, and use them from another)