On 30 May 2014 08:24, Andy Bradford
wrote:
> Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
>
>> Can anyone tell what happens under the hood here..?
>
> Bingo:
>
> http://www.fossil-scm.org/index.html/artifact/d1aef141c961172a1a32f619f339c641cdeaa674?ln=259,268
>
> So it does indeed
On 30 May 2014 08:09, Andy Bradford
wrote:
> Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
>
>> root@main:/tmp/ftmp# f sync f_f -R r_w
>> Round-trips: 1 Artifacts sent: 0 received: 0
>> Error: Database error: unable to open database file: {CREATE TEMP
>> TABLE onremote(rid INTEG
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
> Can anyone tell what happens under the hood here..?
Bingo:
http://www.fossil-scm.org/index.html/artifact/d1aef141c961172a1a32f619f339c641cdeaa674?ln=259,268
So it does indeed call ``fossil http'' which will cause fossil to chroot
a
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
> root@main:/tmp/ftmp# f sync f_f -R r_w
> Round-trips: 1 Artifacts sent: 0 received: 0
> Error: Database error: unable to open database file: {CREATE TEMP
> TABLE onremote(rid INTEGER PRIMARY KEY);}
> Round-trips: 1 Artifacts sent
I was going to +1 sbeals idea, but the pull-only autosync note came up, and
now I think I may not know all there is about autosync. Thanks for keeping
it interesting, folks.
On May 29, 2014 8:34 PM, "Andy Bradford" wrote:
> Thus said Stephan Beal on Thu, 29 May 2014 22:10:24 +0200:
>
> > Wasn't e
Thus said Stephan Beal on Thu, 29 May 2014 22:10:24 +0200:
> Wasn't even aware of pull-only until earlier today. i am completely
> ambivalent on the topic - never had any problems with autosync - this
> was just what came to mind when you posted. Seemed easier than adding
> a new option, but
On 5/29/2014 10:57, Stephan Beal wrote:
after fixing some bits which assumed too much about the signedness of
the (char) data type,
PowerPC does some strange things with char, too. You might have fixed
that in passing.
As a comparison of runtime speeds, here's the results of the core sani
On Thu, May 29, 2014 at 11:38 AM, Andy Bradford
wrote:
> I agree that for network related failures, retry won't help. Others have
> reported non-network related failures (primarily due to locking or other
> similar problems).
Intermittent network failures can be a problem.So, when I'm not at th
Wasn't even aware of pull-only until earlier today. i am completely
ambivalent on the topic - never had any problems with autosync - this was
just what came to mind when you posted. Seemed easier than adding a new
option, but was not aware of the pull-only feature (so a second option
might be simpl
Thus said Stephan Beal on Thu, 29 May 2014 21:44:12 +0200:
> 0 means no autosync, 1 means one attempt (same as now), 2+ means retry
> N times. But because there really is no difference between "try" and
> "retry", 1+ is the same logic:
I assume we're talking about a different setting than
0 means no autosync, 1 means one attempt (same as now), 2+ means retry N
times. But because there really is no difference between "try" and
"retry", 1+ is the same logic:
For(i=0; i < N; ++i) attempt to sync, break on success.
(sent from a mobile device - please excuse brevity, typos, and top-p
Thus said Stephan Beal on Thu, 29 May 2014 18:06:49 +0200:
> That could also (more simply, i think) be interpreted as:
>
> 0 == off
> 1+ == number of times to try
I'm a bit confused, however, in how 0 and 1 should be interpreted...
Given that Fossil currently does 1 autosync attempt: Doe
Thus said Michai Ramakers on Thu, 29 May 2014 17:22:08 +0200:
> Alright, thanks for looking into this (, all). Does this also explain
> my last mail (in case one file is owned root.wheel, and the other file
> and parent-dir are owned ftp.ftp, all works fine)?
I may have mispoken earlier. Fossil
On Thu, May 29, 2014 at 2:52 PM, Michai Ramakers
wrote:
>
> I was thinking the resulting encrypted repo would change a lot, when
> only certain blocks in the unencrypted repo change. Would this not be
> so?
>
When encrypting the file, you should be doing the encryption in CBC mode.
In that case,
On Thu, May 29, 2014 at 2:52 PM, Michai Ramakers
wrote:
> I was thinking the resulting encrypted repo would change a lot, when
> only certain blocks in the unencrypted repo change. Would this not be
> so?
>
I suppose that depends on what software you use to do the encryption.
--
D. Richard Hip
On 29 May 2014 20:40, Richard Hipp wrote:
>
> On Thu, May 29, 2014 at 2:36 PM, Michai Ramakers
> wrote:
>>
>> ...
>>
>> What would work is choose something other than 'fossil sync' to
>> backup, encrypt repos locally and then transfer them, but some of
>> these are fairly large (~ 1 GB) and have
On Thu, May 29, 2014 at 2:36 PM, Michai Ramakers
wrote:
> Hello,
>
> I am planning to keep backups of my fossil repos on a remote site,
> where I have SSH access.
>
> What I would like, is to have at least some way of encryption used on
> the resulting remote repo-files (assuming 'fossil sync' is
Hello,
I am planning to keep backups of my fossil repos on a remote site,
where I have SSH access.
What I would like, is to have at least some way of encryption used on
the resulting remote repo-files (assuming 'fossil sync' is used as
backup method), in case the remote machine gets stolen, say.
Hi, all,
after fixing some bits which assumed too much about the signedness of the
(char) data type, libfossil now builds (slowly!) and runs (slowly!) on
Raspbian OS on Raspberry Pi hardware.
As a comparison of runtime speeds, here's the results of the core sanity
tests on my workstation (a (very
On Thu, May 29, 2014 at 6:22 PM, Michai Ramakers
wrote:
> Right - that's clear, thanks. This is not a big issue and indeed
> eventually always gets solved. Just something new users may encounter.
>
i agree, i just don't see a way to do this consistently (for all commands)
in the current code bas
On 29 May 2014 18:05, Stephan Beal wrote:
> On Thu, May 29, 2014 at 5:45 PM, Michai Ramakers
> wrote:
>>
>> However... is it an idea to at least hint at at permissions being the
>> cause of an error, if it is clear at that point in code? (Errors like
>> the one given in my example-snippet are not
On Thu, May 29, 2014 at 6:00 PM, Matt Welland wrote:
> Retry on autosync would be a big help in my environment. Autosync failures
> due to overlapping access are a regular and annoying occurrence. I like
> Stephan's approach of 0, 1, N for off, on, multi-try
>
That could also (more simply, i thi
On Thu, May 29, 2014 at 5:45 PM, Michai Ramakers
wrote:
> However... is it an idea to at least hint at at permissions being the
> cause of an error, if it is clear at that point in code? (Errors like
> the one given in my example-snippet are not always clear to me.)
>
In fact, you hinted at the
Retry on autosync would be a big help in my environment. Autosync failures
due to overlapping access are a regular and annoying occurrence. I like
Stephan's approach of 0, 1, N for off, on, multi-try
On Thu, May 29, 2014 at 8:49 AM, Andy Bradford wrote:
> Thus said Marc Simpson on Thu, 29 May 20
On Thu, May 29, 2014 at 5:22 PM, Michai Ramakers
wrote:
> Does this also explain my last mail (in case one file is owned
> root.wheel, and the other file and parent-dir are owned ftp.ftp, all
> works fine)?
>
Yes - because the file is owned by root, the "dropping of privileges" is
actually a no-
Thus said Marc Simpson on Thu, 29 May 2014 16:35:50 +0100:
> I'd rather autosync remained a toggle (indicating whether work is
> local or not). A separate setting for number of retries seems
> reasonable.
Well, strictly speaking, autosync isn't a toggle, it can also be set to
``pul
Hello,
[ re recent post about running as root / file-permissions/-ownership / chroot ]
just ran into another thing having to do with permissions - naturally
caused by myself as well. (Running as root, working with repo
containing system-config in /etc and so forth.)
Come to think of it, quite a
Thus said Stephan Beal on Thu, 29 May 2014 17:12:35 +0200:
> i = setgid(sStat.st_gid);
> i = i || setuid(sStat.st_uid);
>
> sure enough. It switches back to the owning user/group of the repo.
>
> IMO, that's not a bug, just an unfortunate side effect of your setup.
In fact, it's intende
Thus said Michai Ramakers on Thu, 29 May 2014 17:08:52 +0200:
> In case both files as well as their parent-dir are owned ftp.ftp, both
> syncs work fine.
Sounds like a simple case of permissions problems to me. The user that
is running the sync must have sufficient Unix filesystem privileges
Thus said Richard Hipp on Thu, 29 May 2014 10:53:57 -0400:
> In my experience, autosync only fails when WIFI is down (or turned
> off). Retries won't help that. It just takes longer to finish.
I agree that for network related failures, retry won't help. Others have
reported non-network relate
I'd rather autosync remained a toggle (indicating whether work is
local or not). A separate setting for number of retries seems
reasonable.
On Thu, May 29, 2014 at 3:56 PM, Stephan Beal wrote:
> On Thu, May 29, 2014 at 4:53 PM, Richard Hipp wrote:
>>
>> On Thu, May 29, 2014 at 10:46 AM, Andy Bra
On Thu, May 29, 2014 at 11:12 AM, Stephan Beal
wrote:
> On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers
> wrote:
>
>> In case both files as well as their parent-dir are owned ftp.ftp, both
>> syncs work fine.
>>
>
> If fossil drops permissions as Andy suggests (i'm still trying to find the
> re
On 29 May 2014 17:12, Stephan Beal wrote:
> On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers
> wrote:
>>
>> In case both files as well as their parent-dir are owned ftp.ftp, both
>> syncs work fine.
>
>
> If fossil drops permissions as Andy suggests (i'm still trying to find the
> relevant code,
On Thu, May 29, 2014 at 10:46 AM, Andy Bradford
wrote:
> Hello,
>
> I introduced some code on the autosync-tries branch that causes autosync
> to retry if it fails, up to a maximum of 3 tries.
>
> 1) Should autosync retry?
>
In my experience, autosync only fails when WIFI is down (or turned off)
On 29 May 2014 17:08, Michai Ramakers wrote:
> On 29 May 2014 16:36, Andy Bradford
> wrote:
>> Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
>> ...
>> I could be wrong, but one thing you could try to verify is:
>>
>> chown ftp.ftp r_w
>> f sync r_w -R f_f
>
> In case both files ar
On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers
wrote:
> In case both files as well as their parent-dir are owned ftp.ftp, both
> syncs work fine.
>
If fossil drops permissions as Andy suggests (i'm still trying to find the
relevant code, but have no reason to believe he's wrong), then that's t
On 29 May 2014 16:36, Andy Bradford
wrote:
> Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
>
>> root@main:/tmp/ftmp# ls -ld * .
>> drwxr-xr-x 2 root wheel 512 May 29 15:32 .
>> -rw-r--r-- 1 ftp ftp3435520 May 29 15:32 f_f
>> -rw-r--r-- 1 root wheel 3592192 May 29 1
On Thu, May 29, 2014 at 4:53 PM, Richard Hipp wrote:
> On Thu, May 29, 2014 at 10:46 AM, Andy Bradford
> wrote:
>
>> 1) Should autosync retry?
>>
>
> In my experience, autosync only fails when WIFI is down (or turned off).
> Retries won't help that. It just takes longer to finish.
>
Maybe inst
Hello,
I introduced some code on the autosync-tries branch that causes autosync
to retry if it fails, up to a maximum of 3 tries.
1) Should autosync retry?
2) Should the number of tries be configurable?
I would like to either merge or abandon, but would like some additional
feedback first. Here
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
> root@main:/tmp/ftmp# ls -ld * .
> drwxr-xr-x 2 root wheel 512 May 29 15:32 .
> -rw-r--r-- 1 ftp ftp3435520 May 29 15:32 f_f
> -rw-r--r-- 1 root wheel 3592192 May 29 15:32 r_w
> root@main:/tmp/ftmp# f sync r_w -R f_f
On Thu, May 29, 2014 at 4:11 PM, Richard Hipp wrote:
> On Thu, May 29, 2014 at 9:57 AM, Stephan Beal
> wrote:
>
>> (B) fossil always chroot's when run as root.
>>
>
> That sounds right to me. Running Fossil as root causes a chroot and
> /var/tmp does not exist inside the chroot jail.
>
In thi
On Thu, May 29, 2014 at 9:57 AM, Stephan Beal wrote:
> (B) fossil always chroot's when run as root.
>
That sounds right to me. Running Fossil as root causes a chroot and
/var/tmp does not exist inside the chroot jail.
--
D. Richard Hipp
d...@sqlite.org
___
On 29 May 2014 15:57, Stephan Beal wrote:
> On Thu, May 29, 2014 at 3:35 PM, Michai Ramakers
> wrote:
>>
>> In short, syncing with repo seems to work or not depending of
>> perms/ownership of that repo:
>>
>> root@main:/tmp/ftmp# ls -ld * .
>> root@main:/tmp/ftmp# f sync r_w -R f_f
>> ...
>>
>> r
On Thu, May 29, 2014 at 3:35 PM, Michai Ramakers
wrote:
> In short, syncing with repo seems to work or not depending of
> perms/ownership of that repo:
>
> root@main:/tmp/ftmp# ls -ld * .
> root@main:/tmp/ftmp# f sync r_w -R f_f
> ...
root@main:/tmp/ftmp# f sync f_f -R r_w
> Round-trips: 1 Art
On 29 May 2014 15:44, Richard Hipp wrote:
>
> On Thu, May 29, 2014 at 9:35 AM, Michai Ramakers
> wrote:
>>
>> In short, syncing with repo seems to work or not depending of
>> perms/ownership of that repo:
>>
>> root@main:/tmp/ftmp# ls -ld * .
>> drwxr-xr-x 2 root wheel 512 May 29 15:32 .
>
On Thu, May 29, 2014 at 9:35 AM, Michai Ramakers
wrote:
> Hello,
>
> ran to something I didn't understand just now, and turned out to be
> (likely) a thing concerning permissions.
>
> In short, syncing with repo seems to work or not depending of
> perms/ownership of that repo:
>
> root@main:/tmp/
Hello,
ran to something I didn't understand just now, and turned out to be
(likely) a thing concerning permissions.
In short, syncing with repo seems to work or not depending of
perms/ownership of that repo:
root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x 2 root wheel 512 May 29 15:32 .
-rw-r-
47 matches
Mail list logo
