The Dave

As we approach 3.5 years since this thread, has Resilio Sync yet been fixed on QNAP?

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.

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.

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.

Great, thanks!

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.

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.

Awesome, thank you! I appreciate it and I'll keep this in mind and do the upgrades carefully!

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.

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?

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?

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!

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.

Thanks!

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.