Sword plugin configuration

[Arthur Trip]

Hi all,
I wonder if there's a qtSword plugin configuration to change the default /tmp directory used for the DIPUpload polling.
In the Atom documentation it is not clear to me if, in the Atom side, some configuration has to be made.

Thanks

Arthy

[Dan Gillean]

Hi Arthy, 

I will try to confirm this with my Archivematica colleagues, but: 

In the last part of this section in the Archivematica docs, we configure the rsync parameters. If you use the example provided, you can see that it adds the rsync target as pointing to AtoM's /tmp folder. In this case, you don't need to change anything in AtoM's default setting for the SWORD deposit directory. If you have made changes on the Archivematica side, then I believe that the purpose of this setting is to allow you to let AtoM know about the change as well, so the qtSwordPlugin knows where to watch for incoming deposits from Archivematica. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/8a3d17d5-f973-4ea3-baa9-81d79a08aa53o%40googlegroups.com.

[Arthur Trip]

Hi Dan,

I tried but it failed.
Archivematica used a different directory as a Rsync target, let say /data/uploads, and the DIP was effectively transferred (it's in /data/uploads, in the AtoM host), but AtoM didn't find it and the corresponding slug is quiet and emtpy (atom-worker is running and all plugins are active).

I thought about using a symlink to have /tmp point to /data/uploads but it seems a very bad idea cause /tmp - as I know - is a system directory.

Incidentally I discovered that the /tmp directory still contains many old uploads; it seems that AtoM didn't clear the /tmp after loading the DIP.

Cheers

Arthy

[Arthur Trip]

Hi Dan,

maybe I didn't understand or the solution was more simple than I thought.

For sure I must change the "Rsync target" in Archivematica but I must also change the "SWORD deposit directory" in AtoM (in Global settings)!

Now it works but again, after the correct upload, all packages still are on the /data/uploads in AtoM VM.

/data/uploads is

drwxrwxrwx. 5 root  root  174 Jul 27 18:09 uploads

while all DIPs are owned by the archivematica:archivematica and the grants are (example):

drwxrwxr-x. 3 archivematica archivematica  99 Jul 27 18:09 {omissis}

and inside the DIP:

-rw-rw-r--. 1 archivematica archivematica 243186 Jul 14 14:42 METS.{omissis}.xml
drwxrwxr-x. 2 archivematica archivematica     61 Jul 14 14:41 objects
-rw-rw-r--. 1 archivematica archivematica   5975 Jul 14 14:42 processingMCP.xml
drwxrwxr-x. 2 archivematica archivematica     54 Jul 14 14:41 thumbnails

I discovered the same behavior also in other two AtoMs 2.5.0 and 2.5.4 installations.

Any suggestion?

Thanks

Arthy

[Dan Gillean]

Hi Arthy, 

Oh, I'm relieved to hear that the setting works as expected! Sorry if my initial explanation was not clear. 

In terms of AtoM not automatically deleting DIP packages after DIP upload is complete: 

I haven't yet had the opportunity to reproduce this behavior, but for now I've preliminarily filed a bug report so we can follow up on it here: 

• https://projects.artefactual.com/issues/13396 

I will say that this bug might be one reason to use the default /tmp location, rather than your AtoM uploads directory. With a location like /tmp, you could write a simple cron job that clears out the directory on a weekly, or even nightly basis. When using uploads, you risk deleting all of your AtoM digital objects with that approach, unless the rules for deletion are VERY carefully crafted and tested. 

I will try to update this thread when we learn more, but keep an eye on the related issue ticket. And if this is a priority fix for your institution and you might want to sponsor a bug fix for guaranteed inclusion in the next AtoM release, please feel free to send an email to info [at] artefactual [dot] com, and our team can prepare an estimate for you. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/97af96fd-71a6-4d30-a2f9-aa34224e1fbdo%40googlegroups.com.