Skip to first unread message
Elizabeth Thomson
Nov 28, 2017, 3:02:59 PM11/28/17
to AtoM Users
Hi,
From time to time we discover what look like temp files in the AtoM installation directory with names of the form 'magick-####' where # is an alphanumeric character
I'm guessing these are ImageMagick temp files. Is this a symptom of a misconfiguration in our installation? Is it safe to delete these files ?
I've been deleting these files, but we recently noticed that a number of digital objects that had been loaded into AtoM a while ago are no longer present in the uploads directory although the records for them in the digital_objects table are still in the database. We discovered this when we ran the regenerate digital derivatives job following an upgrade. I can't find any indication that deleting imageMagick temp files is a bad thing, but I'm wondering if it was a mistake to delete the apparent temp files in the atom installation directory.
Any thoughts/suggestions/speculation as to what may have happened, would be greatly appreciated !
Thanks.
Elizabeth Thomson
Nov 28, 2017, 3:06:02 PM11/28/17
to AtoM Users
I have a related question: The records for the digital objects are still in the system, but of course the files themselves are missing.
Is there a way to reupload the missing files without deleting and recreating the records ?
Many thanks.
Elizabeth Thomson
Nov 28, 2017, 4:03:28 PM11/28/17
to AtoM Users
One further point which may be germane: the uploads directory in the AtoM home directory is a symlink to a mounted volume.
Dan Gillean
Nov 28, 2017, 4:30:21 PM11/28/17
to ICA-AtoM Users
Hi Elizabeth,
I'll have to ask a developer to respond to this one. In the meantime, can you please remind me of some of the details of your AtoM installation? Version, operating system and PHP version, webserver, etc. Thanks!
--
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-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/da8b5e70-c89a-49c1-831d-bbdc52c12385%40googlegroups.com.
Elizabeth Thomson
Nov 28, 2017, 4:35:33 PM11/28/17
to AtoM Users
My apologies! I should have included this info.
AtoM 2.4.0
RHEL 7.4
PHP 5.5.38
ImageMagick 6.7.8
nginx 1.10.2
On Tuesday, 28 November 2017 16:30:21 UTC-5, Dan Gillean wrote:
Hi Elizabeth,I'll have to ask a developer to respond to this one. In the meantime, can you please remind me of some of the details of your AtoM installation? Version, operating system and PHP version, webserver, etc. Thanks!
On Tue, Nov 28, 2017 at 4:03 PM, Elizabeth Thomson <elizabet...@mcgill.ca> wrote:
One further point which may be germane: the uploads directory in the AtoM home directory is a symlink to a mounted volume.
On Tuesday, 28 November 2017 15:06:02 UTC-5, Elizabeth Thomson wrote:I have a related question: The records for the digital objects are still in the system, but of course the files themselves are missing.Is there a way to reupload the missing files without deleting and recreating the records ?Many thanks.
On Tuesday, 28 November 2017 15:02:59 UTC-5, Elizabeth Thomson wrote:Hi,From time to time we discover what look like temp files in the AtoM installation directory with names of the form 'magick-####' where # is an alphanumeric characterI'm guessing these are ImageMagick temp files. Is this a symptom of a misconfiguration in our installation? Is it safe to delete these files ?I've been deleting these files, but we recently noticed that a number of digital objects that had been loaded into AtoM a while ago are no longer present in the uploads directory although the records for them in the digital_objects table are still in the database. We discovered this when we ran the regenerate digital derivatives job following an upgrade. I can't find any indication that deleting imageMagick temp files is a bad thing, but I'm wondering if it was a mistake to delete the apparent temp files in the atom installation directory.Any thoughts/suggestions/speculation as to what may have happened, would be greatly appreciated !Thanks.
--
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 post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
Dan Gillean
Nov 28, 2017, 4:47:00 PM11/28/17
to ICA-AtoM Users
Thanks!
Regarding your question about re-uploading the images without deleting the descriptions:
Given that AtoM thinks there is already a digital object attached, I think the best way to attempt this would be to use the new update option for CSV import. Your workflow would look something like this:
- Find the descriptions with missing digital objects, and add them to the clipboard. If there's a lot in the same series or fonds, remember that you can pin the parent to the clipboard and include all descendant records in the clipboard export
- Export the records
- Open the CSV locally, and delete any information found in the digitalObjectUri, digitalObjectPath, and/or digitalObjectChecksum columns for those records
- Add your digital objects to a directory in the root AtoM directory (let's call it replacements)
- In the CSV, add the full file path information to the related digital object in the digitalObjectPath column - for example, if your installation is located at /usr/share/nginx/atom, and image01.jpg is the image you want to attach, the full path might be /usr/share/nginx/atom/replacements/image01.jpg
- Import the file using the match and update option. I recommend using the "skip unmatched" option too, to avoid accidentally creating new duplicate descriptions
You could do this either from the command-line, or via the user interface. Docs here:
- UI: https://www.accesstomemory.org/docs/latest/user-manual/import-export/csv-import/#update-existing-descriptions-via-csv-import
- CLI: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/cli-import-export/#importing-archival-descriptions
I haven't tried this myself yet, so I'm not totally sure how it will respond to replacing something that is not actually there, but I'm hoping it will work! If you try it, let us know how it goes!
Cheers,
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/29963683-4a15-46ed-84b3-a300814acae5%40googlegroups.com.
Elizabeth Thomson
Nov 28, 2017, 4:59:20 PM11/28/17
to AtoM Users
Many thanks indeed Dan. I'll let you know how it goes if we end up using this.
best regards.
sbr...@artefactual.com
Dec 4, 2017, 7:42:21 PM12/4/17
to AtoM Users
Hello Elizabeth
>> I'm guessing these are ImageMagick temp files. Is this a symptom of a misconfiguration in our installation? Is it safe to delete these files ?
You are correct - these 'magick-####' files are ImageMagick temp files. ImageMagick will create temp files like this when it needs to cache data when delegating to other processes. Sometimes if ImageMagick is interrupted, these temporary files can be left behind. It is safe to delete any file with the pattern you describe: 'magick-####'. Doing this will not affect digital objects that have been succesfully loaded into AtoM.
Regarding the missing AtoM digital objects:
"The records for the digital objects are still in the system, but of course the files themselves are missing.
Is there a way to reupload the missing files without deleting and recreating the records ?"
There isn't currently a way to re-associate an uploaded file with an existing digital object record via AtoM's web interface. Selecting "Import Digital Objects" when viewing the digital obbject record or viewing the parent record as Admin will create a new digital object record.
You definitely will see these digital_object records in the database where the digital asset has been removed. These records will contain the filename and the former path where the asset was located. The complication is that this table will also contain data rows for any derivatives generated during the upload process. I do not recommend using this information to try to re-attach the digital assets without extensive testing as any mis-identification of the database rows and file paths will cause additional corruption in your system.
Steve
Reply all
Reply to author
Forward
0 new messages