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 .
On Thu, May 29, 2014 at 9:35 AM, Michai Ramakers m.ramak...@gmail.com
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:
On 29 May 2014 15:44, Richard Hipp d...@sqlite.org wrote:
On Thu, May 29, 2014 at 9:35 AM, Michai Ramakers m.ramak...@gmail.com
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
On Thu, May 29, 2014 at 3:35 PM, Michai Ramakers m.ramak...@gmail.com
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
On 29 May 2014 15:57, Stephan Beal sgb...@googlemail.com wrote:
On Thu, May 29, 2014 at 3:35 PM, Michai Ramakers m.ramak...@gmail.com
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
On Thu, May 29, 2014 at 9:57 AM, Stephan Beal sgb...@googlemail.com 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 Thu, May 29, 2014 at 4:11 PM, Richard Hipp d...@sqlite.org wrote:
On Thu, May 29, 2014 at 9:57 AM, Stephan Beal sgb...@googlemail.com
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
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
When
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.
On Thu, May 29, 2014 at 4:53 PM, Richard Hipp d...@sqlite.org wrote:
On Thu, May 29, 2014 at 10:46 AM, Andy Bradford amb-fos...@bradfords.org
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
On 29 May 2014 16:36, Andy Bradford
amb-sendok-1403966191.gpijlhaollnogheom...@bradfords.org 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
On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers m.ramak...@gmail.com
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
On 29 May 2014 17:08, Michai Ramakers m.ramak...@gmail.com wrote:
On 29 May 2014 16:36, Andy Bradford
amb-sendok-1403966191.gpijlhaollnogheom...@bradfords.org 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:
On Thu, May 29, 2014 at 10:46 AM, Andy Bradford amb-fos...@bradfords.org
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
On 29 May 2014 17:12, Stephan Beal sgb...@googlemail.com wrote:
On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers m.ramak...@gmail.com
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
On Thu, May 29, 2014 at 11:12 AM, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers m.ramak...@gmail.com
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'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 sgb...@googlemail.com wrote:
On Thu, May 29, 2014 at 4:53 PM, Richard Hipp d...@sqlite.org wrote:
On Thu,
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 related
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 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 intended
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
On Thu, May 29, 2014 at 5:22 PM, Michai Ramakers m.ramak...@gmail.com
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
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 amb-fos...@bradfords.orgwrote:
Thus said Marc
On Thu, May 29, 2014 at 5:45 PM, Michai Ramakers m.ramak...@gmail.com
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,
On Thu, May 29, 2014 at 6:00 PM, Matt Welland estifo...@gmail.com 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
On 29 May 2014 18:05, Stephan Beal sgb...@googlemail.com wrote:
On Thu, May 29, 2014 at 5:45 PM, Michai Ramakers m.ramak...@gmail.com
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
On Thu, May 29, 2014 at 6:22 PM, Michai Ramakers m.ramak...@gmail.com
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
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
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.
On 29 May 2014 20:40, Richard Hipp d...@sqlite.org wrote:
On Thu, May 29, 2014 at 2:36 PM, Michai Ramakers m.ramak...@gmail.com
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
On Thu, May 29, 2014 at 2:52 PM, Michai Ramakers m.ramak...@gmail.com
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.
On Thu, May 29, 2014 at 2:52 PM, Michai Ramakers m.ramak...@gmail.com
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
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
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: Does 0
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
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 the
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
On Thu, May 29, 2014 at 11:38 AM, Andy Bradford amb-fos...@bradfords.org
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
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
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 was
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 amb-fos...@bradfords.org wrote:
Thus said Stephan Beal on Thu, 29 May 2014 22:10:24
41 matches
Mail list logo
