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: 0
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
On 30 May 2014 08:09, Andy Bradford
amb-sendok-1404022150.hdbpagcekdcgljghk...@bradfords.org 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
On 30 May 2014 08:24, Andy Bradford
amb-sendok-1404023072.eeipjlgjbincchjbb...@bradfords.org wrote:
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200:
Can anyone tell what happens under the hood here..?
Bingo:
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
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 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
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
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
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
21 matches
Mail list logo
