errors comparing MAC files

[albertedgar]

I'm using DiffMerge to confirm the integrity of an archive, so only equality matters.
I'm getting thousands of red stop sign errors with folder compare.
Double clicking brings up the message "Cannot compare these items. Both objects must be regular files"
To test, I copied a folder with offending files onto the desktop, and made a second copy of the same folder on the desktop with a different name. I opened each folder and made sure permissions of all enclosed items were set to read/write.
The offending files can be opened in TextEdit.app to see words in the files, and the offending files from both folders appear identical in TextEdit.
MAC OS 10.6.1 on MacBookPro, DiffMerge 3.3.0 (1001)

[Beth]

You ran a folder diff on the two you copied to the desktop? If so, what were your results?

[albertedgar]

Thank you!

Out of 238 files in the test folder on the desktop, DiffMerge has a red stop sign on 6.

I tried comparing the same folder from the desktop to itself (not the identical copy). DiffMerge gives a warning that the folders are identical and Folder Diff Window will not report any differences, are you sure you want to open this window? When I click Yes, it again shows the 6 with red stop signs.

Checking again, an offending file shows "Read & Write" for "Albert (Me)" and can be opened and viewed in TextEdit.app. Double clicking on one says "Error! Cannot compare these items. Both objects must be regular files."

[jeffhostetler]

You might try changing the "File Equivalence Mode" to "Use Exact Match Only"
(on the "Equivalence Mode" Page in the Preferences Dialog) and see if that helps.

When using Exact Match Only, I just do raw byte-for-byte comparisons of each
pair of files. In the other modes, I make some assumptions about the files that
may not be true in your case (for example, that they are actually plain text files
and not something like RTF).

Let me know if that doesn't help with the problem.

j

[albertedgar]

In "Folder Windows > Equivalence Mode" preferences is set to "Disable File Equivalence Testing -- Use Exact Match Only".
I experimented with that earlier, Restore Defaults resets it to that Exact Match state used in the reported tests.

These are early files in the archive, circa 1998, I think they are MAC files from Quark, Netscape, etc. without file extensions. They have gone through storage on NTFS disks, which is were they are being retrieved and placed on the Snow Leopard desktop in HFS+. But the interpretation of the bits is irrelevant to archiving them as just a pile of bits, they have a lot of memories.

[jeffhostetler]

I dug up that error message in the source.
It gets set when either of the items is not
a regular file or a directory.

Is it possible that the items are symlinks
or some other type of special file?

j

[albertedgar]

Got it! After learning what Symbolic Links were in Wiki, I started copying files out to see if they would work independently. The filenames of the offending files all contained slashes for dates! For example "Quark Patents 98/SDC IR linear rev2/3/98". (SDC - Surface Defect Correction - is one of my inventions that a decade later is a standard on almost all film scanners in the world). The slashes made it appear in the DiffMerge readout to be the file "98" within layers of folders. DiffMerge is confused by the name.

Renaming "/" to "-" let DiffMerge say the files were equal, proving the hypothesis.

A slash is an allowed character in a MAC name. In fact, adding a slash to the name of a file in HFS+ that had compared correctly caused DiffMerge to flag the file as an error. Because "/" is an allowed character, this could be classified as a bug, although it is a character that is rarely used.

Thank you very much for your help. If you do fix this arcane problem, please tell me, else I'll just not compare those files for now.

[jeffhostetler]

Thanks for the explanation. I'll log this, but I doubt that it'll ever get fixed. Sorry.

FWIW, slashes in filenames are a problem.

And there are several things going on under-the-hood.
With OS X, Apple uses '/' for the pathname separator whereas in the past, they used ":"
and they now swap those characters in various contexts. For example, open a Finder
window and right click and create a new folder "a/b/c" -- this displays just fine. If you
open a Terminal window and do an "ls", you'll see "ac".

If the files were on NTFS (which doesn't allow either character in filenames), the
slashes probably got converted to some special high-bit character while they were there.

There are probably other things lurking -- such as burning the files to a CD or DVD -- that
may cause subtle problems later.

It may be worth the effort to rename them permanently.

j