On Thu, Oct 25, 2012 at 11:02 PM, Thornton, Susan M. (LARC-B702)[LITES] <[email protected]> wrote: > Hi Helix, > We had a hardware failure on one of our assetstore file systems recently > and I'm working on verifying the restore worked properly (it didn't as I'm > finding lots of duplicate files and files at depth level 3). > > Yes, I understand that in the bitstream table, "store_number" tells > DSpace where to find the file and the "internal_id" tells DSpace 2 things: > 1. which subdirectory in that store_number the file > resides (according to the first 6 digits) > 2. what the actual file name is > > What a mess! > Thanks for your reply - it was as I thought it was! > Sue
You may be lucky (as strange as it may sound) if you're getting whole files, which would indicate that just the filesystem was corrupted, not the contents of bitstreams. It should be possible to find the right location for files. If I were you, I'd make a list of all the files (find /dspace/assetstore -type f) then look up their names in the "bitstream" table, then take the corresponding checksum and run md5sum on the bitstream to verify its integrity. As for locations within assetstore, if the bitstream name is correct, it's easy to find the directory by the first three numbers of bitstream filename. If bitstream filename is corrupted, it would be harder. You could make a list of all their md5 sums and then do the lookup I mentioned in reverse - find the bitstream filename by its md5 sum in the "bitstream" table. Good luck! Just ask if you're in doubt. Regards, ~~helix84 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
