Hi Karl,

The Apache redirect option is more difficult than it might sound, as this is passed off to a Perl handler.  You woudl need to add a specific exception like:

push @{$c->{rewrite_exceptions}}, '/29788/1/my_file_20190404.pdf';

To your archive's cfg/cfg.d/ directory, lets say in a file called z_rewrite_exceptions.pl and then edit both your archive's cfg/apachevhost.conf and ssl/securevhost.conf to add the exception:

RewriteEngine on
RewriteRule /29788/1/my_file_20190404.pdf http://YOURHOSTNAME/29788/7/my_file_20190510.pdf [P,L]

You would want to make sure you use http in apachevhost.conf and https in securevhost.conf.

Regards

David Newman

Thanks David,

Sounds a very involved process and I’m not sure I’m willing to risk damaging the database to fix this up.

Another (equally hacky) option might be using an apache redirect for the missing files, if the affected parties feel strongly enough about it.

Karl.

On 24 May 2019, at 4:07 pm, Newman D.R. <drn@ecs.soton.ac.uk> wrote:

Hi Karl,

The only way I have found to do this is remove all uploaded documents and then re-add in the order they were originally added.  In your case:

my_file_20190404.pdf (that is now actually a copy of my_file_20190510.pdf)

then

my_file_20190510.pdf

However, as you can see that the numbers are not just 1 and 2 but 1 and 7 originally. This means the indexer has run and generate thumbnails and other auxiliary files in between.  So to make sure that the numbers are the same you would need to hit "Save and return" after the first upload, make sure the indexer has run to reindex that item and generate thumbnails and then upload the second item.  If you cannot see if the EPrint has been re-index from the event queue, I would wait at least 20 minutes or so before uploading the second file. (Edit lock can last for a while after saving and if the item is in the event queue with an edit lock it will get postponed 10 minutes).  I would also advise having a test run with a completely separate EPrint with some test files, so you can see  that your repository will behave the same as I describe.

If this does not work, unfortunately I think the only way to fix this is hacking around moving files and modifying the database.  This is far from ideal and I have to admit this it is something that has caused me problems in the past.  Maybe others have found a workaround that I am not aware of, so it maybe worth waiting if my first approach does not work before resorting to the really hacky solution.

Regards

David Newman

On 24/05/2019 00:40, Karl Goetz via Eprints-tech wrote:

Hi,

I haven’t managed to find a solution to this so I’m hoping someone has some experience in this area.

I have a situation something like this:

• Staff member creates empty eprint 29788
• Staff member uploads the first version, my_file_20190404.pdf, as supplied by academic. URL is /29788/1/my_file_20190404.pdf
• Staff member uploads revised version, my_file_20190510.pdf, as supplied by academic. URL is /29788/7/my_file_20190510.pdf
• Staff member removes first version, my_file_20190404
• Academic asks for the first version to be re-instated as it had been hot linked to
• Staff member uploads a copy of my_file_20190510.pdf as my_file_20190404.pdf. URL is /29788/13/my_file_20190404.pdf

This matches the expectations set out in the documentation where each upload was recorded separately as a file but I can’t find anything covering ‘undeletes'

https://wiki.eprints.org/w/EPrints_Directory_Structure/eprints3/archives/ARCHIVEID/documents/disk0/00/00/00/01/01

Can I re create file 01 and add it back to eprints, using means fair or foul?

We’re using IRStats2 for tracking access so a solution would need to work with that - otherwise I'll simply tell the staff member in question we can’t fix the deletion.

Thanks,

-- 

Karl Goetz

Mon, Tue, Wed, Technical Services Officer - eResearch

Wed, Thu, Fri Senior Library Officer (Library Systems)

University of Tasmania, Private Bag 25, Hobart 7001

University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

Virus-free. www.avg.com

-- 

Karl Goetz

Mon, Tue, Wed, Technical Services Officer - eResearch

Wed, Thu, Fri Senior Library Officer (Library Systems)

University of Tasmania, Private Bag 25, Hobart 7001