Nick,
   Except (correct me if I'm wrong) I believe the ignore feature won't prevent the files that RTC doesn't control from being deleted. This is one of the really big pain points to me as well. I have a folder where a component is loaded which also contains other folders and those other folders need to remain/be ignored at all operations.

For example, Microsoft's Embedded platform builds in c:\winceXXX, so the component needs to be loaded in this folder. The only problem is we don't want to check in all the files in the \WinceXXX folder because it could total out to be around 40gb even without our source code. We don't unload the workspace thats loaded into Wince in fear it will blow away installed files. If something happens to the Wince folder it would take a better part of a day (maybe a 1.5 days) to reinstall the Embedded platform.

RTC is the only source control system I've worked so far that controls the entire folder structure where the components are loaded. This wouldn't be so bad if the scm system would honor the ignore files for 'Unloading a workspace' and in a build definition of 'Delete Directory before loading".There isn't an easy way to find the ignore file that is ignoring the file you want to update and this doesn't even count for the eclipse ide ignoring files. We had a case where we had a file called rcs that we wanted checked in but the eclipse editor was ignoring RCs file. Which on a Linux system are two different files. It caused a developer all kinds of grief until we figured that out.

Sorry if my comment is a bit winded.

No worries, that all makes sense. Is there some top-level directory structure under c:\winceXXX that needs to be protected, or are the files you load mixed in to the existing directory structure? I'm not actually sure how the ignore mechanism treats folders, but I can check with someone from the SCM team, and/or try to model your situation.

You don't have to check with the SCM team. I fairly certain there are some work items already created to address some of my issues. I must have not bookmarked the particular WI.

Yes there are folders at c:\winceXX that need to be protected.
c;\wince\public (28.4 gb) - Unless we need to change something here, I'm not checking this into RTC.
c:\wince\Platform (292mb) (We have modified some folders here, we only checked in the platforms we changed)
c:\wince\others (515 mb)
c:\wince\Source1 (2.32 gb) - This is our source folder

The jazz folders at the same level. We have a couple other source folders but those aren't very big at all. So out of fear of screwing up those folders I have the workspace disconnect instead of delete. Then I go there and delete the folders that I know of. Luckily we don't change out this workspace very much.

Frankly, there is a level of complexity where you don't need it. If RTC didn't own the workspace then you wouldn't need ignore files and then it would only concert itself with the files that were added in manually. RTC tries to be nice and add in files for you but the side effect is deleting of files it doesn't own.

The root file/folder/symbolic link that is loaded from an SCM repository workspace are are what we consider a "share". if the share is a folder, everything in it and below is considered under SCM control and it is intended to map 1 to 1 with the contents in the repository unless specifically ignored (as Nick explained).  Sibling file/folder/link that are in the same directory as the share are not considered under SCM control and should not be deleted by SCM during an load/unload.

As well a share does not need to be loaded directly under the sandbox. There can be a path to it not under source control that leads to the share.  I am not exactly sure what you are loading where that is causing difficulties. An example may help.

If c:\wince is the sandbox, then loading a folder Source1 from the repository workspace should have no effect on the c:wince\others c:wince\public since these are siblings that are unshared in the sandbox.

I am guessing here, but suspect the difficulties you have are with the c:\wince\Platform folder where there are somethings under source control and somethings not. If in your repository component you have a folder structure "Platform\abc\ourSource\" and you on disk have a folder "Platform\def\someOtherSrc" and you want "abc" & "def" to co-exist, you do not want to load the folder Platform from your repository workspace. Instead you want to load "Platform\abc" and you want it to be loaded in sandbox c:\wince under the folder "Platform". The folder "Platform" in the C:\wince directory is not under source control. "abc" is the share and it will co-exist with other items in the same directory like "def".

With 4.0, we have updated the articles to describe more of the options that you have when loading. If I understand the problem correctly, I think the case you are interested in is described in the article on loading. https://jazz.net/library/article/1016#Loading_into_a_specific_folder_structure

Load rules work on the file level as well. I suspect the NPE encountered is work item 213788 which has been fixed in 4.0.0.1. If you are running a client more recent than that, can you raise a work item with the details.

The article was https://jazz.net/library/article/1016 - Loading Content from a Jazz Source Control Repository in Rational Team Concert 4.0.

We are currently using Loadrules + copy