On Tue, Oct 29, 2024 at 03:33:35PM +0000, Tim Young wrote:
> I am a linux tech who is helping some librarians debug their dspace.  The 
> complaint is that they are seeing some error pages after clicking on the 
> "pdf" link after looking at an item.
> Whitelabel Error Page
> This application has no explicit mapping for /error, so you are seeing this 
> as a fallback.
> 
> Tue Oct 29 15:04:16 UTC 2024
> There was an unexpected error (type=Internal Server Error, status=500).
> An internal read or write operation failed
> 
> From what I google; there should be an error message in the dspace.log file, 
> but there are no errors there.  (plenty of recent "INFO" and one or two 
> "WARN" entries, but nothing that looks like it has to do with the above 
> error.)  I verified all the permissions on the assetstore, and they are the 
> same across the board (all files have the same file permissions, and all 
> directories have the same dir permissions)
> 
> Now, for some history:
> 
> This site is relatively new.  The school had an older version dspace for 
> quite some time, but they had a hard-drive go out on them at the same time 
> that they had some issues with their backup. The short of it is that, instead 
> of "upgrading" dspace, like we had planned, we ended up installing a clean 
> dspace 7.6 and re-entering their heaps and piles of items.
> 
> Many of the items which are in their dspace work fine.  But a number of items 
> do not.  I am suspicious of the "failing" items, as the dates 
> (dc.date.accessioned, dc.date.available, which appear to be the dates that 
> the items were entered) are from years ago.  We literally built this thing 
> less than a month ago and the dates are showing between 3 and 5 years prior.  
> I suspect that someone imported some dumps from the past, and those dumps did 
> not include the actual items.  But that is my suspicion.
> 
> Is there a way to verify that the bitstreams (I believe this is the correct 
> word; I am looking for the files themselves) exist for the items in the 
> database?  Can we dump a list of items without bitstreams?  And, what would 
> be the procedure for entries that no longer have items associated with them?  
> Delete and re-add, or can they upload a new item to an existing entry?
> 
> Again, I am an IT guy who is mainly helping out, so I apologize for not being 
> immersed in dspace and knowing everything I should about the tools available 
> to me.

Understood.  DSpace uses some of these terms differently so, to avoid
confusion:

o  an Item is a DSpace abstraction in the database, which represents a
   set of files and the metadata which describe the set.

o  a Bitstream is a DSpace abstraction in the database, which
   represents a file in the filesystem and metadata which describe it.
   One article of metadata is the name under which the file was
   submitted.

o  the actual files are spread randomly through an Assetstore directory
   tree, and each is named by a hash of its content.  They are placed
   in directories named by the first few characters of the hash, so
   assetstore file 93948004603449655886343619484568742798 would be
   found as '93/94/80/93948004603449655886343619484568742798' under
   the assetstore root.

It's possible to have multiple Assetstores but you probably don't.  To
find the root of the single assetstore, you can use 'bin/dspace dsprop
-property assetstore.dir'.

I'm not sure what pieces you believe to be missing.  To find
Bitstreams representing files that don't exist in the assetstore, you
could walk the Bitstream database table and look up each row's
'internal_id' column value in the filesystem.  The 'internal_id' is
just the hash -- you'll need to compute the path as noted above.

It is possible to delete an existing bitstream from, and to up load a new
one to, an Item when logged in with appropriate rights (such as a
member of the Administrator group).  Navigate to the Item, use the
pencil / Edit this item button at top right, select the Bitstreams
tab, and you'll see a list of bitstreams with action buttons, plus
uploading controls at the top.

There is another abstraction that you'll see there:  the Bundle.
Bitstreams are contained in Bundles which are contained in Items.  You
probably want to upload to the ORIGINAL bundle -- the others contain
ancillary or derived files such as thumbnail images, license texts,
and extracted flat text for indexing, and should normally be treated
as opaque implementation details.

In case you haven't already found it:  the Official Documentation is
at https://wiki.lyrasis.org/display/DSDOC7x

If you have further questions, please ask.  If the documentation is
unclear, please say so!

If you can get more details on how the content of the repository was
rebuilt, it may be helpful in finding the best way forward or, at
least, understanding the repository's current state.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
library.indianapolis.iu.edu

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/dspace-tech/ZyJ_JqJgnaaJSDKB%40iu.edu.

Attachment: signature.asc
Description: PGP signature

Reply via email to