About ingestion and retrieval

I created an ingestion job under a certain preservation plan, but I realized that it is not the plan I wanted to use. What should I do?

The ingestion job has already been defined and cannot be deleted. It will be best used for an ingestion that does need of the preservation plan set at the job’s creation moment.

For the desired ingestion, the desired preservation plan will have to be defined, then assigned to the preservation area, and then an ingestion job created in that area.

An ingestion job has failed for not complying with the ingestion checks. I have checked the contents of the object and have found a Thumbs.db / desktop.ini / .DS_Store / other file that I had not created and that has been the reason for rejecting the ingestion job. What has happened?

An ingestion job is following a preservation plan. If this plan has a good design approach in checking the object’s contents, if an ‘uninvited’ file appears in the object, the ingestion job may fail.

But, why should a file just appear in an object? Some operating systems such as Windows and MAC OS X, and sometimes also some of the applications they run, generate specific support files to fulfill some tasks. This is, for example, the case of the Thumbs.db files which are file thumbnails for file listing in the file explorer, or the desktop.ini files which are files with autorun configurations, or the .DS_Store files similar to the previous. When a copy of an object is done from a system to another, the operating system may detect the files being of a specific type and decide to carry on some of its support actions, and so generating those system files.

It is necessary to expressly configure the operating system (and any background application) not to create these files, both in the LIBSAFE server and in those intermediate systems through which the objects will be copied before making it to the temporary ingestion folder. This configuration is the responsibility of the managers of those systems.

Anyway, and to protect the composition of the objects, it is convenient to make use of the ingestion sanitizers to assure the compliance with the object ingestion composition. These sanitizers may detect those files and delete them, without failure for the ingestion job, and assuring the correct composition for the object.

A collection of objects have been ingested with an improper plan. / Some duplicate versions of objects already ingested have been detected. / Some objects don’t need to be preserved any longer. / ..... Is there any way to delete these objects from the system, to free up the space they use?

NO; nothing that is inserted in the system can be deleted. LIBSAFE is a preservation system and, as such, it must comply with the established conventions for this kind of systems. To preserve implies to keep everything forever. Because of this, it is highly advisable to carefully design the procedures that will lead to the object ingestion.

I tried a retrieval of all objects in a preservation area but the application didn’t allow it, stating that the retrieval was for a size of objects greater than a certain quantity. How can I avoid this restriction?

Retrieve jobs are processes that use resources; both in terms of processing during retrieval, as of space to leave the retrieved object in the temporary interchange storage. To avoid collapsing the system, retrieval for users without special permissions is limited; should you need to avoid this limit, contact your system administrator for him to grant you the necessary permission. Beware! Before launching a massive retrieval job, make sure there is enough space in the temporary interchange storage, and that the action is not going to interfere with the normal use of the application by other users.