I have a directory that must not exist on logout and rm -rf is not
sufficent to do it because the contents need to be processed by our
version control system. The real life scenario is our version
control system stores the repo for a given project encrypted but for
techinical reasons it needs to
On Thu, 9 Sep 2010, Aryeh Friedman wrote:
I have a directory that must not exist on logout and rm -rf is not
sufficent to do it because the contents need to be processed by our
version control system.
=
what i would do... make an alias or function of "logout" and/or "exit"
Perhaps you could write something to wrap your shell... basically you
could set your login shell to this wrapper. First thing the wrapper
would do is exec and wait on the shell, and when the shell exits,
check what needs to be checked, and should any of these checks fail,
respawn the shell and dump
On 09/10/10 05:27, Aryeh Friedman wrote:
I have a directory that must not exist on logout and rm -rf is not
sufficent to do it because the contents need to be processed by our
version control system. The real life scenario is our version
control system stores the repo for a given project encryp
On Fri, 10 Sep 2010, Ivan Voras wrote:
1) power outage of the server
2) power outage on the client
3) network problems (ssh or TCP connection drop)
4) administrative command (e.g. root executes "killall $shell")
?
I don't think there is a way to protect from all of those, so any effort
in pro
On 10 September 2010 14:11, Atom Smasher wrote:
> On Fri, 10 Sep 2010, Ivan Voras wrote:
>
>> 1) power outage of the server
>> 2) power outage on the client
>> 3) network problems (ssh or TCP connection drop)
>> 4) administrative command (e.g. root executes "killall $shell")
>>
>> ?
>>
>> I don't
On Thu, Sep 9, 2010 at 8:27 PM, Aryeh Friedman wrote:
> I have a directory that must not exist on logout and rm -rf is not
> sufficent to do it because the contents need to be processed by our
> version control system. The real life scenario is our version
> control system stores the repo for a
The problem with that is our version control system (devel/aegis)
purposely does not allow arbitary checkins... there is a whole
procedure of you have to prove it compiles and passes at least one new
test and then an other person needs to review the change and then and
only then can it be checked i
On Fri 10 Sep 2010 at 10:09:20 PDT Aryeh Friedman wrote:
The problem with that is our version control system (devel/aegis)
purposely does not allow arbitary checkins... there is a whole
procedure of you have to prove it compiles and passes at least one new
test and then an other person needs to r
On 09/09/2010 23:27, Aryeh Friedman wrote:
> I have a directory that must not exist on logout and rm -rf is not
> sufficent to do it because the contents need to be processed by our
> version control system. The real life scenario is our version
> control system stores the repo for a given projec
On 09/10/2010 22:21, jhell wrote:
> On 09/09/2010 23:27, Aryeh Friedman wrote:
>> I have a directory that must not exist on logout and rm -rf is not
>> sufficent to do it because the contents need to be processed by our
>> version control system. The real life scenario is our version
>> control s
On Fri, Sep 10, 2010 at 10:30:35PM -0400, jhell wrote:
> On 09/10/2010 22:21, jhell wrote:
> > On 09/09/2010 23:27, Aryeh Friedman wrote:
> >> I have a directory that must not exist on logout and rm -rf is not
> >> sufficent to do it because the contents need to be processed by our
> >> version con
On 09/11/2010 05:07, Peter Pentchev wrote:
>
> ...but, of course, that's only until people learn that they can
> bypass this by something like 'kill -FPE $$'.
>
Have you tried that ?
If the person/developer is looking into it that far where they need to
subvert the logout process then there is
>
> Firstly this just sounds like a case where the admin needs to provide a
> equally sound and safe way of making sure everything is cleaned up on
> logout and is offering a global way of doing it so the developer will
> not forget.
In this case the admin and developer are the same person... name
On Sat, Sep 11, 2010 at 7:07 AM, Aryeh Friedman
wrote:
>>
>> Firstly this just sounds like a case where the admin needs to provide a
>> equally sound and safe way of making sure everything is cleaned up on
>> logout and is offering a global way of doing it so the developer will
>> not forget.
>
>
On 09/11/2010 07:13, Aryeh Friedman wrote:
> On Sat, Sep 11, 2010 at 7:07 AM, Aryeh Friedman
> wrote:
>>>
>>> Firstly this just sounds like a case where the admin needs to provide a
>>> equally sound and safe way of making sure everything is cleaned up on
>>> logout and is offering a global way of
Aryeh Friedman wrote:
> In this case the admin and developer are the same person... namely at
> the clients request I am the only person allowed to work on the
> project and I just want to make it so I can't accidently do something
> like control-d or something like that and leave a plain text
I would prefer to have the plain text around after a power failure
because it could be several days of work and as I said the only reason
for all this is to make the client comfortable and not that I do not
trust the team (I do trust them)
On Sat, Sep 11, 2010 at 11:10 AM, Oliver Fromme wrote:
>
On 9/11/2010 10:18 AM, Aryeh Friedman wrote:
ys of work and as I said the only reason
for all this is to make the client comfortable and not that I do not
trust the team (I do trust them)
Write a script that gets executed in the background once you log in that
will periodically check to make s
For reasons explained in an earlier reply this is a very *BAD* idea
due to how devel/aegis is structured
On Sat, Sep 11, 2010 at 12:32 PM, Joshua Isom wrote:
> On 9/11/2010 10:18 AM, Aryeh Friedman wrote:
>>
>> ys of work and as I said the only reason
>> for all this is to make the client comfort
Aryeh Friedman wrote:
> I would prefer to have the plain text around after a power failure
> because it could be several days of work ...
Ideally there should be _some_ mechanism for committing unfinished
work to a (probably encrypted) repository on, at least, a daily
basis.
The more I see of t
Since we have been using aegis for years and know it like the back of
our hand I don't want to learn a new tool... but I think your right I
am going to forward/cross post this entire thread to the aegis mailing
list.
On Sat, Sep 11, 2010 at 7:11 PM, wrote:
> Aryeh Friedman wrote:
>
>> I would p
Atom Smasher wrote:
On Fri, 10 Sep 2010, Ivan Voras wrote:
1) power outage of the server
2) power outage on the client
3) network problems (ssh or TCP connection drop)
4) administrative command (e.g. root executes "killall $shell")
?
I don't think there is a way to protect from all of those,
23 matches
Mail list logo
