[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EP-tech] Re: Can't hide histories from simple users only
- Subject: [EP-tech] Re: Can't hide histories from simple users only
- From: hess at ub.uni-heidelberg.de (Florian Heß)
- Date: Tue, 28 Feb 2012 15:05:26 +0100
- In-reply-to: <EMEW3|8707364e0391ef46141c6c6c1b0eae51o1NDvF14eprints-tech-bounces|ecs.soton.ac.uk|1330091815.4468.15998.camel@chassis.ecs.soton.ac.uk>
- References: <4F2BC5F9.4010009@ub.uni-heidelberg.de> <1329498370.4468.2187.camel@chassis.ecs.soton.ac.uk> <EMEW3|0752cf10f6977c0147b1abe577cf7317o1GH6D04tdb2|ecs.soton.ac.uk|1329498370.4468.2187.camel@chassis.ecs.soton.ac.uk> <4F421E10.3080805@ub.uni-heidelberg.de> <EMEW3|dae558dad7cc3afcc78cd13da253b8c6o1JALO14eprints-tech-bounces|ecs.soton.ac.uk|4F421E10.3080805@ub.uni-heidelberg.de> <4F423CFE.2090709@ub.uni-heidelberg.de> <1329743284.4468.10111.camel@chassis.ecs.soton.ac.uk> <1329744560.4468.10133.camel@chassis.ecs.soton.ac.uk> <EMEW3|c5494ac62832697b37670dc85d54bda3o1JDUo14eprints-tech-bounces|ecs.soton.ac.uk|1329744560.4468.10133.camel@chassis.ecs.soton.ac.uk> <4F465F1D.401@ub.uni-heidelberg.de> <1330091815.4468.15998.camel@chassis.ecs.soton.ac.uk> <EMEW3|8707364e0391ef46141c6c6c1b0eae51o1NDvF14eprints-tech-bounces|ecs.soton.ac.uk|1330091815.4468.15998.camel@chassis.ecs.soton.ac.uk>
Am 24.02.2012 14:56, schrieb Tim Brody:
> On Thu, 2012-02-23 at 16:45 +0100, Florian He? wrote:
>> Hence, WHAT exactly has been deleted here? :-)
>
> That removed revision files for me.
>
Hi,
so at last I see why not only the webserver user should be in eprints'
main group but also vice versa: For instance, only then eprints user can
delete files created by a webserver process.
Now I got still to figure out why deletion fails for some files.
$file->remove returns a false value in those cases. The sources suggest
that can happen only when the file path is undefined (how come?), or
when system call unlink() returns false. The latter is rather unlikely
as I succeeded deleting the file manually as user eprints.
Therefore I debugged a bit and it turned out that method
EPrints::Plugin::Storage::Local::_filename (line 203ff) returns an empty
array in the case that $eprint is undefined... does that mean I cannot
get rid of histories and revisions associated with eprints that have
already been removed? Is it intended that those survive the deletion at all?
By the way, while testing that, there I guess would be no need for
run/restore loops if EPrints removed the file record *upon successful*
deletion of the file itself.
By another way heading a better users' experience: When cancelling the
creation of an eprint in the web interface workflow, i.e. with all
fields left empty, you still have to delete the eprint entry from the
database manually in order to keep your inbox clear. Potentially annoying.
Regards,
F He?
> You may need to manually remove revision files if they have no
> associated history object ...
>
> /Tim.
>
> *** 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/
--
UB Heidelberg (Altstadt)
Pl?ck 107-109, 69117 HD, Germany
- Informationstechnik
- WWW-Redaktion
http://www.ub.uni-heidelberg.de/