Searching compressed files is no big deal. First of all, you can always
decompress. But if they've just been compressed and not put in a tarball or
some other archive format, you can just use zgrep.

However, many if not most files are in structures that don't lend
themselves to just scanning for text patterns so you usually have to
convert it to something else so you can analyze it.

To get an idea of the problem, try opening a bunch of non textual files in
Notepad and see how easy it is to find known content in those files. If the
info you're interested in is actually stored in a database structure where
the bits of info you need are scattered across different locations, it gets
much harder.

Simple scans through files for specific info can be productive, but it's a
messier process than it might appear on the surface.


kyle


On Tue, Oct 15, 2013 at 10:31 AM, don warner saklad
<[log in to unmask]>wrote:

> For the "My Lists" feature what steps are actually involved retrieving an
> altered/deleted listing like "[_] Record b2491348 is not available
> 03-12-2013" by that bibliographic reference code from the 7 month system
> backup? Perhaps the backup is compressed and searching a compressed file is
> a barrier for what could otherwise be relatively straight forward with
> something like grep
> http://en.wikipedia.org/wiki/Grep
>
> In the future when we have real computers it'll be trivial to get
> information from a backup with the reference code.
>
>
> On Tue, Oct 15, 2013 at 12:32 PM, McDonald, Stephen <
> [log in to unmask]> wrote:
>
> >
> >
> > > a) Forensics studies deal with how to retrieve "deleted" "unarchived"
> > data. So called "deleted" data is actually available.
> >
> > Computer forensics cannot always get the data back.  Television crime
> > shows greatly exaggerate the capabilities of computer forensics.  It
> > depends on what format the data was in, how the data was deleted, and
> what
> > has happened on the computer since it was deleted.  Even in the cases
> where
> > it is possible, it requires taking the system offline (making it
> > unavailable for other people to use), requires specialized software, can
> > take days of work, and often can retrieve only part of the data.  This is
> > not feasible in a working database like your library network.
> >
> > > b) Setup the system not to delete records belonging to users. Let users
> > keep their information saved for followup. Or at the very least notify
> > users beforehand.
> >
> > Millennium cannot do that.  The only internal mechanism in Millennium to
> > prevent records from being deleted is by controlling who can perform
> > deletions.  There is no mechanism in Millennium to notify either the
> person
> > deleting or the owner of a review file that a record being deleted is in
> a
> > review file.  It is not feasible for someone deleting records to manually
> > check every review file to see whether a record is in one of them.
> >
> > The only way to control deletions is by careful training, limiting who
> can
> > delete data, and establishing policies on when and how data are deleted.
> >  This is something between you and the consortium, but it sounds like
> > Minuteman has established policies and is following them.
> >                                         Steve McDonald
> >                                         [log in to unmask]
> >
>