If this particular archiver code was stored at some site (hopefully APS) in
remote accessible CVS then it would be possible for knowledgeable persons to
apply patches given that the original author no longer works in the
collaboration.
>
> > Actually, AR does a core dump. No intentional aborts as far as
> I can see.
> > Maybe we just have a REALLY old version of AR.
>
> It calls assert(), which calls abort() when it fails, which generates a
> SIGABRT signal, which will cause a core dump if the current working
> directory is writable.
>
> See assert(3) and abort(3).
>
> It is quite intentional, and this isn't the only place AR dies in response
> to a condition which is not a true error condition. Among other
> things, it
> does not distinguish between a write "failure" due to the max file size
> being exceeded and an actual error in writing to the file.
>
> ARR has similar problems. For instance, if you are retrieving
> data and the
> file size has changed since the last retrieval, it aborts(). Using the
> "resync" item in the "retrieve" menu will prevent that. If the size
> changes in the middle of the retrieve, you lose regardless. This makes it
> harder to use on a "live" archive file than it should be.
>
Jeff
- References:
- Re: EPICS archiver Brian McAllister
- Navigate by Date:
- Prev:
EPICS on vxWorks/x86 john sinclair
- Next:
RE: security windows for EPICS Jeff Hill
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EPICS archiver Brian McAllister
- Next:
EPICS training Bob Dalesio
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|