Can I copy files – but with certain restrictions?

When I select File> New Shell I now get:

+Last login: Fri May 28 16:46:13 on ttyp4+
+Welcome to Darwin!+
+jenny-pearces-imac-g5:~ Jenny$+

and I am able to type in simple commands. Before I trashed my preference folder, I did not get this simple message. but the one previously posted.

When I double click on consolidate14 I get:

+Last login: Fri May 28 16:46:17 on ttyp5+
+/Volumes/C-Data/Consolidate\ Test\ Files/consolidate14.command; exit+
+Welcome to Darwin!+
+jenny-pearces-imac-g5:~ Jenny$ /Volumes/C-Data/Consolidate\ Test\ Files/consolidate14.command; exit+

+Consolidate14 script revised 2010-05-25 10:00 P.M.+

+Folder not specified. Type the path to the top-level folder or drag+
+it into this Terminal window, then click back in this window and press return:+

And the script stops at the LordB2002.mp3 file. I don't think the script stops at 10,000 lines like I assumed. It seems to stop every time at this file which has two checksums that are both: 037e57b3870f9186739c11c1d8b94c11

I thought consolidate14 might have been corrupted, so I unzipped it again and the same thing happens. That suggest to me there is something sus in OSX or elsewhere that Terminal or the script is accessing.

I'm going to restore my OSX and all software. No big deal, I do that regularly and it only takes about 10 minutes. But first I'll try it on another of my OSXes. I've got three separate OSXes on separate drives, and the others are virgins, shall I say.

There were four checksums for LordB2002 in two failed runs for which I saved the Terminal output, all identical: 037e57b3870f9186739c11c1d8b94c11

The result of running the command you gave was the same.

With a brand new OSX and Terminal in place, I'll run again tomorrow.

I've started testing consolidate14 again. All runs are on a backup 59.3 GB folder with ~11,300 files on an external FW drive. Between runs I restore the folder from the original folder using SilverKeeper, in case anything changed.

In all cases I created a new shell, dragged consolidate14 to the window, dragged the folder to the window, and selected "n" so that no files are moved.

*Run 1* (buffer = 10,000 lines) -- completed in 5741 seconds.

*Run 2* (buffer = unlimited) -- failed at LordB2002.mp3

*Run 3* (Quit Terminal, buffer set to 10,000, clicked on "set as default") -- failed at LordB2002.mp3

*Run 4* (Quit Terminal, buffer came up as "unlimited", reset to 10,000, clicked on "set as default") -- failed at LordB2002.mp3

I've posted about not being able to set 10,000 as the default ( http://discussions.apple.com/thread.jspa?threadID=2444078&tstart=0), because I thought that might be causing the problem.

Any idea how I can reset Terminal to its defaults?

This is a summary of what I have discovered about consolidate14 and Terminal.

1. With a brand new Terminal, set to the default 10,000 line buffer, the first run works.

2. I assume all subsequent runs would also work. Will try and test that on another of my OSXes.

3. If "unlimited scrollback" is selected in Terminal, the script stops somewhere after 3000 lines. The number varies. It does not stop because of a particular file. I removed LordB2002 and the script stopped at another file.

4. Once "unlimited scrollback" is selected, the Script never again completes a long run, and there appears nothing you can do about it -- except reload OSX.

If I can get the script running on another OSX, I'll try several runs to prove point 2. Otherwise I'll try the other Terminal mentioned by Robert.

This is the result of testing consolidate12 using a backup Test folder of 8.0 GB with 2047 files, of which maybe a few hundred are duplicates. Test (not its real name) is a sub folder of my Archive folder.

1. I restored OSX from a diskimage that I have for just this purpose, to a partition on an external FW drive. It's a brand new OSX with nothing else on the partition. I booted into that OSX.

2. I dragged consolidate12 to the Terminal window, followed by Test, and selected "n" so that files were not moved. 435 seconds later the script finished a complete run.

3. I repeated 2. The script completed the run in 388 seconds.

4. I repeated 2 again – completion time 388 seconds.

5. I ran SilverKeeper to restore Test to its full complement of files. I checked that the original Test and the backup Test were identical by running Toast's Compare utility. About 10 minutes later the answer came back: "The folders are identical". I should be back where I started at step 2.

6. I repeated step 2. The run failed.

7. I quit Terminal, deleted the "plist" preference file, and repeated step 2. The run failed.

8. I deleted the "plist" file again and rebooted, then repeated step 2. The run failed.

9. I rebooted into my normal OSX (which had already been through several failed runs), repeated step 2, and the run failed.

It seems to me that the problem is connected with restoring my Test folders with SilverKeeper. If I run the script on a large folder, it will complete the task. If I then restore the folder so that I can test again, the script fails -- even though the folder is reported by Toast (and SK) as being identical to the original. The failure is then permanent. Nothing except a new OSX will make the script run correctly again.

I had an idea that maybe Terminal, plist, or the script were being corrupted. But when I compared them with the same three files on another pristine OSX partition, Toast report all three as being identical.

I'm at a loss to explain how this could happen. Identical software running on an identical folder, but because the folder has undergone a restore, the software fails. The problem only occurs with folders above a certain size. When I ran similar tests to the above on a much smaller folder, including the use of SK, the script always completed its run.

Any ideas as to why the script is failing to complete its run?

I looks to me like the script will be useful when I finally come to use it, but this problem with restoring means I can't test it thoroughly.

Thanks for the suggestions, Robert. Unfortunately, CCC is not as flexible as SK. Several years ago I extensively tested CCC, and most other cloning software, and for my purposes SK came out on top. For example, CCC cannot clone sub-folders to sub-folders (which is what I want to do while testing) and anyway, CCC takes about 10 times as long to clone (see the last post, and the third before that (mine) at http://forums.bombich.com/viewtopic.php?t=15540).

The Compare utility within Toast reports that: "The folders are identical" before each test run, so I assume they are. Maybe there is an invisible file within my test folder that SilverKeeper puts there which is causing the problem, but which the Compare utility does not detect.

RE XCode, I don't think I have that, and if I remember correctly from a post of mine years ago, it is not possible to put it back without doing a complete reinstall of OSX. But if you can tell me how to get it back, I'll give it a go.

I've been following a few trails trying to crack the problem with this script, and now I may have nailed it. Something along the lines of: if an item is already in the trash from a previous run, and the script tries to trash the same item on a subsequent run (because the folder being checked has been restored to its original condition), the script stops. That's my theory (at least for a large number of items in a folder) and it's backed up by:

1. If I run the script and it completes it run, there will be items in the Trash.

2. If I +don't+ restore the folder and run the script again, it completes the run. BUT, if I do restore the folder and run the script again, the script will fail.

3. BUT, if I restore the folder +and+ empty the trash, then run the script, it completes it run.

I'd like to alter the script so that instead of sending items to the Trash, it instantly deletes them. This is the relevant part of the script (+consolidate16+):

# Check each checksum against the sorted list, beginning at the current cell position in the array
# If a matching checksum is found, trash the matching file and wipe out it's values in the array
# If no match is found then break, the list is sorted so once there is no match we're done
for ((j=$((${i}+1));j<${count};j++)) ; do
[ -z "${filePath[${j}]}" ] && continue
if [ "${fileSum[${i}]}" = "${fileSum[${j}]}" ] ; then
mv "${filePath[${j}]}" ~/.Trash 2>/dev/null || mv "${filePath[${j}]}" ~/.Trash/$RANDOM
echo "${filePath[${j}]}" | tee -a "${MainFolder}/Consolidate_Trashed_List_${runDateTime}.txt"
filePath[${j}]='' fileSum[${j}]=''
else
break
fi
done

Does anyone know how to make a simple change to that part of the script, so that instead of trashing, the items are instantly deleted?

Re iTerm (already tested after it was suggested): it gave the same results as Terminal.