on from the master showed correct file permissions.
> But changing permissions after that initial step doesn't seem to change
> anything.
Hi!
Anyone knows more here? Is fossil capable of keeping and maintaining file
permissions or not? I couldn't find any hint in the documentation
On Wed, Dec 2, 2009 at 3:59 PM, Tino Lange
wrote:
> Anyone knows more here? Is fossil capable of keeping and maintaining file
> permissions or not? I couldn't find any hint in the documentation/wiki -
> and
> the experiments yield ambigous results.
>
>
Fossil records only t
On Mar 6, 2018, at 5:30 PM, Scott Doctor wrote:
>
> Any suggestions what to check?
File permissions, SELinux, web server permissions…there’s a whole pile of
things that can go wrong here.
I just heard that the venerable Unix and Linux System Administrator’s Handbook
came out in a new v
Barry Kauler wrote:
Hi!
>4. Fossil does not record permissions and ownerships of files.
Is that true?
A quick experiment with a 755 and 644 file, checked in in my working
repository, synced to the master repository and checked out at another
location from the master showed correct f
fo/134c7881cc,
> it should give a major performance boost for larger repositories.
> It doesn't handle file permissions at the moment though.
Thank you. Will try tomorrow.
Sincerely,
Gour
--
Gour | Hlapicina
xport/import spec is broken or Git's
> implementation?
Git's implemenation of fast-import is broken when you try to actually
use for incremental imports.
You might want to try http://fossil.sonnenberger.org/info/134c7881cc,
it should give a major performance boost for larger repositorie
builds just ignore the
additional fields? Then there is no problem.
This reminds me of another (maybe can of worms) idea: Why not let
users add J fields per repository, they could be used to store file
permissions etc, but are the responsibility of the repository, not the
fossil
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
the problem.
I'll try current tip a bit later (when I get a chance), but I really don't
understand how a file from last year works, and one from this year (built
with the same version of fossil, using almost identical script) doesn't. I
there anything besides capabilities and uni
now handle --x (executable bit))
I'm guessing this means that file permissions aren't maintained through
the check-in/check-out process(?) Do you have a link to --x
documentation or can you provide an example?
> in a controlling file. Something like a purpose-built makefile or
> script th
ing almost identical script) doesn't. I
> there anything besides capabilities and unix file permissions that can
> affect permission to write to a fossil file?
>
You also need write permission on the directory that holds the
*.fossil file, in order to create the journals.
--
D. Richard Hi
e rejected.
>
> This reminds me of another (maybe can of worms) idea: Why not let users
> add J fields per repository, they could be used to store file permissions
> etc, but are the responsibility of the repository, not the fossil
> executable.
>
>
>
>
>
>
Hi, all,
some people have bemoaned Fossil's lack of file permissions support over
the years. Initially, Fossil did not track _any_ permissions, but the
executable bit was eventually added because it is common practice to have
an executable configure script in the source tree.
What i didn&#
all of the changed files over from the broken checkout, then
check them in from the clean checkout directory.
If that works, then I would look at local file permissions.
You’re doing this on Windows, yes?
> I tried to do a commit as I have not done so in a while
Commit early, commit often!
also be good to be able to limit Administrator access to
> only the local PC or local LAN, is there a way to do this?
You mean the administration of the fossil project right? Windows does
have file permissions, and the user that fossil is being run as is up
to you. Sadly this is so over complic
ecks before evaluating the *nix
file permissions. As the zip format is widely spread and has many
different implementations with presumably different robustness (my two
examples, again: 7-Zip creating directories instead of empty files,
older WinZip ignoring empty files), it may always require some
co
and
call fossil through cgi direclty, reading through 1 or 2 line cgi scripts
dosn't seem much, but it is unecessary for a service like this (creating
the scripts for each user/repo setting file permissions, etc...) when I can
just point fossil where the directory or repository is.
I do know
At Thu, 7 Jun 2012 12:11:00 +0200,
Stephan Beal wrote:
> And i would go one step further and NOT use fossil for the system files.
> Fossil does not support file permissions
> other than the +x bit and does not understand user/group ownership. Without
> that, using it for managing
s of
passwords? Similar to a "fossil ui" in the sense that "administrative
ownership" of the database is ultimately enforced by file permissions / host
environment.
and yes clearly this would be the same level of security as a single shared
user. although that bridge is
On Sep 19, 2013 1:38 AM, "Stephan Beal" wrote:
>
> Hi, all,
>
> some people have bemoaned Fossil's lack of file permissions support over
the years. Initially, Fossil did not track _any_ permissions, but the
executable bit was eventually added because it is common pra
tools are designed for.
Er, I don't expect the SCM to behave in all respects like an installed
copy of the project. Well, perhaps it would be nice if it did, but
where Fossil cannot handle it, file permissions/ownership for example,
I also have workarounds, in my case a post-checkout script.
On May 12, 2015, at 2:31 PM, Matt Welland wrote:
>
> Does your team use Unix file permissions to prevent people from viewing files
> they have no right to be looking at?
Are you suggesting that Fossil needs to implement a per-artifact ACL system?
Yes, I realize this is a slipp
zero-effort way to achieve the same end, as long as you
> can be sure all privileged users must use it.
It's not zero-effort if you want Fossil Privileges and Capabilities
enforced on the server. Only if you don't mind that all SSH users have
the same privileges is it
lots of CGI scripts around when I could just ask the database and
> call fossil through cgi direclty, reading through 1 or 2 line cgi scripts
> dosn't seem much, but it is unecessary for a service like this (creating
> the scripts for each user/repo setting file permissions, etc...)
t; This reminds me of another (maybe can of worms) idea: Why not let users
>> add J fields per repository, they could be used to store file permissions
>> etc, but are the responsibility of the repository, not the fossil
>> executable.
>>
>>
>>
>>
>>
network printer in department X with constant printouts.
I’m saying you may have a people problem, rather than a technical
problem. This is a matter for management, not IT.
Different strokes for different folks I guess. Does your team use Unix
file permissions to prevent people fr
d in clear text over the wire. I
think stunnel works on windows. Good question about the max number of
login attempts.
> - It would also be good to be able to limit Administrator access to
> only the local PC or local LAN, is there a way to do this?
You mean the administration of the fossil
On Tue, May 12, 2015 at 1:51 PM, Warren Young wrote:
> On May 12, 2015, at 2:31 PM, Matt Welland wrote:
> >
> > Does your team use Unix file permissions to prevent people from viewing
> files they have no right to be looking at?
>
> Are you suggesting that Fossil
m the start. (I’m not laying blame, I’m just
pointing out that different goals get different results.)
4. fossil mv and rm don’t behave like POSIX requires unless you give --hard or
build Fossil in a nonstandard way and set an option that’s cleared by default.
5. Fossil’s understanding of file perm
nd that I don't want
> having lots of CGI scripts around when I could just ask the database and
> call fossil through cgi direclty, reading through 1 or 2 line cgi scripts
> dosn't seem much, but it is unecessary for a service like this (creating
> the scripts for each user/
, see below.
>
And i would go one step further and NOT use fossil for the system files.
Fossil does not support file permissions other than the +x bit and does not
understand user/group ownership. Without that, using it for managing
system-level files is a disaster waiting to happen. If certain
tbook:~/fossil-test$
>
> Is there also a technique to then tell the instance of fossil on the
> server to use some arbitrary internal fossil user for the connection
> regardless of passwords? Similar to a "fossil ui" in the sense that
> "administrative ownership" of t
etc.
So symlinks, with nested repos is a huge win for me. Fortunately, I only
need to set up a new course occasionally, so I only have to fight with
Fossil about symlinks occasionally, but too often!
The poor support for symlinks is far and away my biggest complaint with
Fossil. (The limited su
:51 PM, Warren Young wrote:
>
>> On May 12, 2015, at 2:31 PM, Matt Welland wrote:
>> >
>> > Does your team use Unix file permissions to prevent people from viewing
>> files they have no right to be looking at?
>>
>> Are you suggesting that Fossil
> > files.
>>
>> I would keep two different repositories. For the second one, see below.
>>
>
> And i would go one step further and NOT use fossil for the system files.
> Fossil does not support file permissions other than the +x bit and does not
> understand user/grou
can have actual file permissions to read/write the
file, but using ``fossil http repo.fossil'' will also dicate who can
actually commit changes.
If I understand what you are suggesting is that Fossil user amb can
checkout the repo using a Unix user account other t
le problem, rather than a technical
> problem. This is a matter for management, not IT.
>
Different strokes for different folks I guess. Does your team use Unix file
permissions to prevent people from viewing files they have no right to be
looking at?
In my experience there are many
Themes -> ../Themes
> JScript -> ../JScript
> index.html -> current/index.html
> etc.
>
> So symlinks, with nested repos is a huge win for me. Fortunately, I
> only need to set up a new course occasionally, so I only have
12 at 11:30 AM, Joan Picanyol i Puig <
> lists-fos...@biaix.org> wrote:
>
> > * Andrew Stuart [20120531 16:15]:
> > > There are source code files and also operating system configuration
> > > files.
> >
> > I would keep two different repositories. For t
[fossil-users] Make a CGI request WITHOUT a script file
> Message-ID:
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Mar 2, 2012 at 6:04 PM, Guillermo Estrada >wrote:
>
> > Hi, I've been trying to implement a webservice that host
40 matches
Mail list logo
