On the WebCT Users email list (hosted by Blackboard) there is a discussion about a mysterious directory called unmarshall which suddenly appeared. We found it under similar circumstances as others by investigating why a node consumed so much disk space. Failed command-line restores end up in this unmarshall directory.
Unmarshalling in Java jargon means:
converting the byte-stream back to its original data or object 1
This suspiciously sounds like what a decryption process would use to convert a .bak file into a .zip so something can open the file.
This is fourth undocumented work space where failed files site for a while and cause problems and no forewarning from the vendor.
Previous ones are:
- Failed UI backups end up in the weblogic81 (Vista 3, does this still happen in Vista 8?) directory.
- Failed tracking data files end up in WEBCTDOMAIN/tracking (Vista 3, apparently no longer stored this way in Vista 4/8 according to CSU-Chico and Notre Dame)
- Web Services content ends up in /var/tmp/ and are named Axis####axis. These are caused by a bug in DIME (like MIME) for Apache Axis. No one is complaining about the content failing to arrive, so we presume the files just end up on the system.
#3 were the hardest to diagnose because of a lack of an ability to tie the data back to user activity.
Is this all there are? I need to do testing to see which of these I can cross off my list goring forward in Vista 8. Failed restores are on it indefinitely for now.
🙁
References:
Leave a Reply