-- See if the item exists at the destination
      try
        set l_dest_item to get item (name of l_source_item) of l_dest_folder
      on error l_error
        set l_copy_item to true
      end try

Compare the code for retrieving the destination folder with the above code to retrieve the destination item. Since we know what the parent folder is, we can as the parent folder for an item with the same name as the source item. In contrast, we didn't have the parent folder of the destination folder so we couldn't do the same thing there and had to go through the rigamarole of string manipulations.

Previously I said that I didn't want an l_destination_folders queue because it doubles the memory used to store folders. So why do I have an l_pending_folders queue? I can just go down alphabetically and every time I encounter a folder, process that folder immediately (making it a depth first search), then when I'm coming back out I know the folder I just left so I can continue alphabetically scanning the parent folder. Therefore I could do the whole thing without any queues. Frankly I just thought of that now, but even so one pending folders queue makes it a lot easier. Once you have the first queue the second queue does not make the coding that much easier so intuitively I feel the memory usage of the second queue outweighs the benefits.

      -- Check to see if source and destination differ.
      if (l_copy_item is false) then
        if (class of l_source_item is not equal to class of l_dest_item) then
          -- First check class of items
          set l_copy_item to true
        else if (class of l_source_item is not folder and modification date
            of l_source_item is not equal to modification date of l_dest_item) then
          -- Second, check date of items. Only for non-folders
          set l_copy_item to true
        end if
      end if

Simple enough, we're only filtering out items with the same class and same modification dates of the source items. Note that it's pointless to compare modification dats for folders because that reflects if their contents have changed and they'll almost always be different than the source folder. I tried to compare by file size with somewhat unpredictable results, probably because I'm backing up from Mac OS X HFS+ to Mac OS 9 HFS+. This is the perfect place to add a call out for customization so that people can add their own filters.

        -- Copy source to destination
        if (class of l_source_item is folder) then
          -- If source is a folder then create destination folder
          set l_folder to make new folder at l_dest_folder
          set name of l_folder to (name of l_source_item)
        else
          -- If source is not a folder then copy it to destination
          with timeout of 86400 seconds -- 1 day timeout
            try
              duplicate l_source_item to l_dest_folder with replacing
            on error l_error
            end try
          end timeout
        end if

The last part of the code is copying the file if needed. Note that if it's a folder we're not copying it, just creating it. Mostly this is so that I don't accidentally copy a folder full of big files -- I'd rather copy it one file at a time and have more control. There is a know issue where if the destination "folder" is really a file, the create and rename folder fails. This comes about because if I try to delete the item, which is mounted on an AppleShare volume, the Finder asks me if I want to delete it immediately which I can't answer or even know about in the script. Alternatively I can move the file to a makeshift trash folder, which will be a future enhancement.