Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File support #5

Open
Floppy opened this issue Oct 13, 2017 · 6 comments
Open

File support #5

Floppy opened this issue Oct 13, 2017 · 6 comments

Comments

@Floppy
Copy link
Contributor

Floppy commented Oct 13, 2017

Command line should accept:

  • ID
  • Metadata list
  • File

File hash should be stored in DLT, along with the metadata and ID.

Currently, we're just hashing the metadata, not a separate file. That's the bit that needs adding.

@Floppy
Copy link
Contributor Author

Floppy commented Oct 13, 2017

Could use DROID to do the hashing of the file, which is a National Archive tool for creating IDs of digital records: https://www.nationalarchives.gov.uk/information-management/manage-information/policy-process/digital-continuity/file-profiling-tool-droid/

@Floppy
Copy link
Contributor Author

Floppy commented Oct 13, 2017

We can use DROID locally (it's a java app I think), or we could wrap it in a simple API and deploy it somewhere. Maybe.

@Floppy
Copy link
Contributor Author

Floppy commented Oct 13, 2017

DROID might be difficult actually, as it looks like a GUI tool. Not sure if there's a version we can call directly somehow.

@jezhiggins
Copy link
Member

Using DROID sounds sensible.

The user guide is all GUI GUI GUI, but there is a command line driver for it too - see http://digital-preservation.github.io/droid/

@Floppy
Copy link
Contributor Author

Floppy commented Oct 13, 2017

ah, brilliant 😄

@jezhiggins
Copy link
Member

Spent a little bit of time working with DROID. It turns out it isn't what we think it is. It isn't a tool for generating file signatures, it's a file format identification tool. If you give it a load of files, it will chew through them and spit out a list of filenames and file types (those types being in the form of references to their PRENOM database http://www.nationalarchives.gov.uk/PRONOM/BasicSearch/proBasicSearch.aspx)

The command line usage is straightforward enough (if a little chatty and with Spring logging splurting out on stderr) and the output is amenable to parsing, but it does need a bit of management. The signature files it uses need to be downloaded on first use and periodically refreshed. It's not immediately clear if we can control where those files get downloaded to (it's dropping them under ~/.droid6/...). There are some other little funnies too - it has a option to list the downloaded signature files, giving their filenames, but when specifying the signature to use you have to provide the full path name, which obviously needs a bit of meta-knowledge.

DROID clearly has a role to play then, but I'm now might not be the time :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants