Orphan Attachments 07/31/2018I have been doing some housekeeping lately and I've noticed that I had a lot of orphaned attachments. Attachments get orphaned when the PM or post is deleted without removing the attachment first. Deleting a PM or post does not delete the attachment and the file or image remain on the server. I'd like to ask all members to go through their attachments and delete any attachments you don't need anymore or those that have been orphaned. Where can I get a list of my attachments? Click on your display name in the upper right corner of the forums and pick "My Attachments" from the drop-down list. How can I tell an attachment is orphaned? If the PM has been deleted, you'll see a message like this in your attachment list: Unfortunately there is no message if the post has been deleted, so please check your old posts. We do purge old birthday threads every once in a while. Also some hosted projects have been shut down, so you may have orphaned attachments on one of those locations. Thanks!
Search the Community
Showing results for tags 'error'.
Found 1 result
I ran into a really odd problem while fixing a bug and thought I would share it. If anyone has any insight into the problem, please share because at face value, my observations make no sense and should be impossible. After updating a script running on a plate used for cooking in CB an unexpected constellation of variable values hits the scripts and causes an error. The error wasn't fatal and I've found a way to fix it in the meantime, so there is no acute problem. The unexpected constellation was caused by a local update that set all variables to 0 while a quest it interacts with still carries a value that indicates a fire has been found, which is no longer true when the local variables were set to 0. One way that fixed the problem was to set the quest value to 0 at the same time that the other variables were set to 0, but before I hit on that, I found the following problem. Careful tracing of console feedback isolated the problem to this section of code: Note the line in commented with ";once a fire is found", second from the top. This is the console feedback from a run which involves activating the plate near a fire: So if the line mentioned above is doing what it is supposed to and detecting that CBFindFireQ.rCBFireRef is 0, the three lines immediately below it should run. But instead it is clear that the else clause is running instead. The only conclusion I can draw from this is that if eval( CBFindFireQ.rCBFireRef == 0 ) is failing for some reason. Now with a single change to the line of code commented with "; once a fire is found": I get the following feedback: This shows that IsFormValid == 0 is getting the job done. "The Error - Invalid fire" line is running and the script auto-corrects the problem. The one significant difference between Reference == 0 and Reference IsFormValid == 0 is that the latter will treat a disabled Reference as 0, while a disabled Reference will often still have a FormID which should be picked up if the value is non-zero. But for some unknown reason, the check is failing. In this particular case, IsFormValid works fine for the situation, so I have a solid fix for this problem. My concern is more of a theoretical nature, since I can't explain how Reference == 0 fails and I use it deliberately in other cases. My question for the local experts is how can Reference == 0 be failing when the console feedback reports the value of the Reference to be 0000 0000? EDIT: It occurred to me that the problem could, conceivably, relate to the use of eval. I ran an explicit test just like the first one, except the key line read: if ( CBFindFireQ.rCBFireRef == 0 ); once a fire is found The results were identical with those from the test where eval is present. That rules out eval as the source of the problem and thus pushes it into something in the scripting language or a lower level.