Jump to content
  • Announcements

    • AndalayBay

      Orphan Attachments   07/31/2018

      I 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!

About This File

The archive consists of two builds, one good .c file and one bad .c file.

The difference is outlined in diffpatchgoodbad.txt and amounts to pretty much

the omission of the return statement:

 return ((listNumFiles)? listNum: listNum - 1);

in PopulateListBox.

The effects of this are, well amazing. Read on:

Consider the snippet in LBN_DBLCLK:

if (dblclkLevel)	{	if (index > filesIndex + 1) return 0;	}else	{	if (index >= rootFolderCS + rootFolderCW) goto DblclkEnd;	}

In the good build, the value of index in the else block behaves well enough. In the good build, the goto is executed as if the condition is reversed i.e.

if (index < rootFolderCS + rootFolderCW) goto DblclkEnd;

However, in the bad build, change the >= operator to just > and there is no problem. (Needs verification)

 

Seems the compiler doesn't like the goto's as they occupy their own namespace.

In the archive there is also a snippet (don't try and use it) from an older build which had unreachable code warnings generated. I couldn't see then why they should, but suspect it's something to do with another part of the module.

I've gone through it but found nothing that helps, but suspect the lurking bugbear in the program is responsibe for all this behaviour.




User Feedback

Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×