umputun

Well, such time-only-based detection is extremely scary thing. It means if, by some reason, clocks on my computer not in full sync, or if I get from somewhere a file with incorrect timestamp it can cause all sort of interesting issues and lack of ability to delete won't be the worst thing. You can loose all updates of that file because btsync will overwrite it every time with "more recent" version. From another hand, if synced clock is so important for normal functioning of BTSync, it shouldn't even run in such situations but show some warning about time mismatch. As an example of such approach - as far as I remember some of AWS APIs are time-sensitive (for instance SQS) and won't accept request from devices with +/-300sec time offset. UPD: ok, this is not as bad as I thought. Looks like btsync normally ignores such file "from the future". Just tried to make a file with +5mins timestamp and btsync completely ignored this one and didn't sync till I put a valid timestamp.

I double checked all my devices and clocks are fine. Anyway, if by some reason user get a file with such incorrect timestamp, that file becomes sort of "untouchable". Such behavior is very confusing and it is really unclear how to fix it on user's side. Maybe btsync shouldn't allow such timestamps in first place and as it see file in distant future (+5-10 minutes) it will reset modification time to the current local time?

Another bit of info I just discovered - this file has wrong timestamp, something in the future. My local time is 5:51p now, but file shows 6:46p. Probably this is the reason why I can't delete/edit. I don't have any of my computers (admins) with wrong time or incorrect TZ, so not sure how this 6:46p was set. Obviously, I can't say the same about read-only remote clients.

This is part of my log showing the problem: [20130324 17:03:26] File event /Volumes/Internal/radiot.bts/podcast.rss 67584 [20130324 17:03:27] [OnNotifyFileRemove] /Volumes/Internal/radiot.bts/podcast.rss [20130324 17:03:38] SyncFilesController[file removed]: processing file removal /Volumes/Internal/radiot.bts/podcast.rss [20130324 17:03:40] Merge: will request file for /podcast.rss, ltime:1366841018 lhash:1F12910C3CA060F8C1ED1D1FF5D4B39C1261E4C3 rtime:1366847204 rhash:296249FF64DD38E444759F83DA79D2CBE3BB2501 [20130324 17:03:40] SyncFilesController: Got file from remote (95.143.222.146:33333): podcast.rss state: 1 type: FT_FILE total:4 have:4 t:1366847204 mt:1366847198 4509A834A9353A3B79BE30B9F167AB0C19210DBC [20130324 17:03:41] Going to connect to peer 109.254.155.162:36778 for file podcast.rss [20130324 17:03:41] Torrent podcast.rss status: 137 error: <NULL> meta: 1 [20130324 17:03:42] Torrent podcast.rss status: 137 error: <NULL> meta: 1 [20130324 17:03:43] Torrent podcast.rss status: 137 error: <NULL> meta: 1 [20130324 17:03:43] podcast.rss: Piece 0 complete [20130324 17:03:43] podcast.rss: Piece 1 complete [20130324 17:03:43] podcast.rss: Piece 3 complete [20130324 17:03:44] Torrent podcast.rss status: 137 error: <NULL> meta: 1 [20130324 17:03:44] podcast.rss: Piece 2 complete [20130324 17:03:44] Finished downloading file podcast.rss, writing file attributes mt:1366847198 [20130324 17:03:45] Torrent podcast.rss status: 137 error: <NULL> meta: 1 [20130324 17:03:45] Force unloading torrent podcast.rss

Hi, I have some strange behavior and to me it looks like a bug. I have a folder shared with read-only secret across ~100 users. At the same time it shared with full-access secret for some limited number of "admins". Each admin can add new file - this part works just fine. However it seems to be impossible to remove a file - even for admins it acts like "read-only", i.e. removed file get restored automatically. Is this expected behavior or unexpected bug? Any idea how file can be deleted, maybe some workaround?