Hi Deborah,

I manage an openEQUELLA instance. It's not abandonware, it's under the
Apereo Foundation now: https://www.apereo.org/projects/openequella

You could probably pay Unicon or Edalex for one-time support such as help
with a migration. We have an annual contract for support with Unicon and
they're helpful, they have people who have worked on EQUELLA for a long
time.

I have a version of the database schema somewhere but it sounds like that's
not really the problem, you want to know how to convert an item's UUID and
version into the path on the server where its attachments are stored. The
folder is a hash of the UUID calculated in a certain way, here's the script
I use to determine it:
https://gist.github.com/phette23/9279de4260ff681cbdfc12e10275e2d3

So the path to the attachments directory can be constructed like: { data
directory }/Institutions/{ institution name }/Attachments/{ hash of item
UUID }/{ item UUID }/{ item version }

This assumes you're not using advanced storage, which adds an additional
directory in there with the collection's UUID in between "Attachments" and
the UUID hash.

I hope that's helpful. I honestly don't understand much about the hash
itself, I only know that this script works to find it. I'm happy to answer
other openEQUELLA questions. I'm actually surprised to hear someone else
out there uses it, I think this is the first time it's come up on the
listserv.

Best,
Eric


On Mon, Sep 28, 2020 at 2:40 AM Joe Hourclé <[log in to unmask]> wrote:

> I can’t say I’m familiar with the software, but it sounds to me like
> they’re obfuscating the path to slow people who might try scraping the
> archive
>
> It’s likely that the number is in the database, but it might also be a
> value that’s computed based on other information in the record
>
> But before you go and dig through the code, you might have another
> solution .... just looking at the file system. If it’s mounted on a
> Unix-like system you could get a directory report with either ‘du’ (disk
> usage), a recursive directory listing (‘ls -r’ or ‘ls -R’ depending on the
> implementation), or ‘find’ for normal files (‘find directory_to_search
> -type f’)
>
> Of course, then you have to either move the files out of the random
> directory (or symlink them), or take that report, extract the info and
> merge it with your database dump
>
> If I were to try to do it mostly looking from the database side f things,
> I would grab a few records (‘select * from TABLE limit 5’) And then look
> for fields with numbers in them that look out of place
>
> -Joe
>
> Ps. Note to self: Typing Unix commands on a fake keyboard with
> autocorrect really sucks
>
>
> Sent from a mobile device with a crappy on screen keyboard and obnoxious
> "autocorrect"
>
> > On Sep 27, 2020, at 5:43 PM, Fitchett, Deborah <
> [log in to unmask]> wrote:
> >
> > Kia ora,
> >
> > On the off-chance anyone's familiar with (Open)Equella (it's essentially
> abandonware so the ex-vendor's no help, I get error messages when looking
> for the community Google Group, and the only documentation I can find
> helpfully has a page linked from the text "Why does the openEQUELLA schema
> make no sense?"<
> https://openequella.github.io/tutorials/reporting/SchemaDesign.html>
> which is at least reassuring that it's not just me!)
> >
> > I need to migrate out of Equella into another system. I've created a
> report in the SQL database to extract the metadata for the items I need -
> but I also need their files, so I want the filepath on the server.
> >
> > The files are named with the attachment name (which I have), inside a
> directory named with the item id (which I have), inside another directory
> named with a pseudo-random number - ranging from about 0 to about 160, from
> memory. I'm hoping this number is stored somewhere in the SQL database -
> but I haven't been able to find *where*. Help?
> >
> > (I do have other directions I could approach this from but nothing's
> obviously *easy* and I'm not sure of the capacity of the people who
> actually have server access, so, just, argh. Migrations.)
> >
> > Deborah
> >
> > ________________________________
> >
> > "The contents of this e-mail (including any attachments) may be
> confidential and/or subject to copyright. Any unauthorised use,
> distribution, or copying of the contents is expressly prohibited. If you
> have received this e-mail in error, please advise the sender by return
> e-mail or telephone and then delete this e-mail together with all
> attachments from your system."
>