Try copying two items whose names match in every way except case from a local drive to another local drive in the Mac OS X Finder and you’ll see something like this:
Local-to-Local Copy: Just What You'd Expect
This makes plenty of sense. The Finder (actually, the filesystem on which the Finder resides, in this case HFS+) is not case-sensitive by default, so it sees the file “intro.mpg” as being identical to “Intro.mpg” and therefore simply alerts the user of the presence of a like-named file and asks him how to proceed.
But the other day I got the strangest alert I’ve seen in a while when trying to copy a file named “Intro.mpg” from my networked home account to a local folder with a file called “intro.mpg”:
From Network Drive to Local Drive: Case Issues!
Seems that, all of a sudden, we have some case issues. Now why would that be?
It appears that if the originating file comes from my network home, and if that network home lives on an NFS mount, and if the filesystem that hosts that network home is case-sensitive — all of which in this case is true — the Finder kinda freaks out. Or at least alerts the user in a very strange way. I mean, what’s with that wording? I don’t think I’ve ever read a more convoluted sentence in my life. And the options spelled out in that sentence — “skip” or “continue” — are not reflected in the language used by the buttons — “Stop” or “Skip.” Tsk, tsk! And “some of these items?” Dude, it was only one item. I swear.
Actually, this last one I think I understand: Though I was only copying one Finder item, as users of non-HFS filesystems might be aware, copying between HFS and non-HFS filesystems will cause the creation of dot-underscore files, which are there to preserve HFS-specific data about the file in question. These files automatically get created and follow the file around invisibly, transparently to the user. I believe the Finder was taking these additional files into consideration in the alert. This may or may not be true. I can really only guess. But that’s my hunch.
Nevertheless, this alert is abominable, if somewhat amusing. Apple still has some work to do when it comes to the wording in their alerts.
And they clearly have some work to do when it comes to dealing with conflicts on non-HFS volumes as well.
UPDATE:
I’ve changed this post slightly for clarity.
10 Comments
Aside from the wording, it was doing the opposite of freaking out. It was detecting a potential hazard and giving you a chance to stop or throw them off the table. OS X is the only UNIX flavor that doesn’t use a case sensitive filesystem by default. It wasn’t even an option in HFS until Tiger and even then it’s useless due to apps like Photoshop choking because they expect everything to be one case. NFS was merely the innocent bystander. It’ll prompt w/ that anytime you copy from a case-aware volume to case unaware-volume.
It’s definitely more wordy than it should be and it could’ve been made to be plural/singular-agnostic. It’s hard to convey to the user because there could’ve been 5 versions of SomeDocument.foo on the source volume, so you’d have plural overwriting singular, but which one wins? It can’t ask yes or no, so it just asks to skip or stop altogether (the button text actually is logical and totally matches their HIG specification). In most cases there is no way to replace w/out manual intervention. It was just odd in this case because both buttons would’ve resulted in a noop since there was only one file.
Seeing as the screenshot shows an mpeg file, I can confirm there was only one file. Individual files don’t have dotfiles associated with them. It’s not a feature of HFS or any other file system. It’s an arbitrary naming convention to hint to tools like ‘ls’ (and now the Finder) that the file should not be displayed… dates back to the 70s and stems from all the config files users would have in their home directory. Individual apps (or you) can create a file and put a period at the front of its name and it’ll be hidden. It can’t follow another file around automatically. It’ll only get selected when you ether move the parent directory or tell the Finder to show all files and select it explicitly. Dragging a folder will include its .DS_Store. Opening the folder and dragging all its items will not.
The simple way to make this message both clearer and more consistent is to simply make it match the message you’d see when copying between HFS volumes. The problem (a duplicate file) and behavior (replace or not replace) is the same. The different wording never mentions the one thing that is different, which is the filesystem, so why confuse the issue with this freakout of an alert? It’s terrible and I can’t believe anyone would defend it.
And, I’m sorry, but you’re just plain wrong about dot-underscore files. HFS filesystems have always employed the use of dual-fork files. The data fork stores the actual data of the file, and the resource fork contains metadata about the file (like what application opens the file, etc.). When Mac OS X came along and HFS filesystems began regularly interacting with other filesystems that did not support dual-fork files this became a big problem. The resource fork would get lost when copying to non-HFS volumes. The solution was the system of dot-underscore files we have today: when any file on the HFS volume that has a resource fork gets copied to a non-HFS volume, a dot-underscore file (._intro.mpg, for instance) that contains the resource fork metadata gets copied right along with the file, seamlessly and invisibly. Here’s Apple’s KB article on the matter:
http://support.apple.com/kb/TA20578
-systemsboy
Heya…
Agreed that it’s ugly and the wording should be rewritten. I’m not defending a blatant ‘typo’ bug, but they say they don’t support that scenario and have said that for years. You say they ‘clearly need to do more work’ talking non-HFS, but it’s all BSD code! =) The core and the underpinnings you’re referring to are the same exact ones that run half the Internet for decades over. As I originally noted, there could’ve been more than one conflict for the same file and your solution of using the same error would look like it just keeps asking you over and over. The app doesn’t know ahead of time that each one will have a conflict.
Anyhow, I suppose your NFS server could specify the ‘obcaseinsensitive’ flag or whatever it is on NT. The server can then handle cases of *more than two* (I think most servers would munge them to be unique) and let the client not worry about it.
Sorry you think I’m wrong about the resource forks… I’ve been dealing with rsrc shenanigans since the System 5 days and I stand by what I said. =) On the Mac itself, natively dragging the MPEG with the mouse, there was no ._something file. I wasn’t talking about what the Mac exports to other machines to temporarily hold a fork (if one’s avail).
The other note about it becoming a problem now? Nooooo… That’s why that article says they did what they did. It actually didn’t get /better/ until OS X, when they started phasing out the use of forks in general. Pre OS X days, apps/packages/plugins *required* their fork data or they’d be useless. Yet it wasn’t ever extracted out from FS when transferring it around. If you didn’t UU or hex encode each part and make a txt file first, you were screwed and couldn’t transmit it. These days, with all but a couple minor files, you can live without the fork entirely (as mentioned in that article) and the worst that will happen is losing a custom Icon or change the default app association. Even apps/plugins/bundles switched after OS X to a ‘package’ format instead, where it’s all nothing but fork-less data in a folder than masquerades as a file and typically contains two subfolders for resources and data.
But, they also unfortunately created all this confusion when using UNIX conventions for hiding *data* files with a preceding dot. People always think it’s inherently resource stuff, but it’s not. Forks are never forks if you see ‘._foo’… instead it might be a data file that has temporary fork information stuffed inside of it until it makes it back to a fork. On the HFS itself, you merely have the data file which has a UID that maps to a fork elsewhere on the system and it gets extracted and thrown down as a ._foo only when leaving “the bubble” — but even then it’s not critical if it’s lost.
It’s more complicated with .DS_Store. Those are also *data* files that have resource forks of their own. This is because folders can’t have forks so they create a file to hold the icon and dangle the window positioning info in its fork. The dot prefix hides it. These files do hang around all the time and only move around if picked up by the parent folder, just as any other file in the folder would.
Clear as mud right? You can get a visual image… select some of this message’s text and drag it to the desktop to make a clipping. Rename it to foo for simplicity.
Jump into Terminal, then run:
ls -la ~/Desktop/
File is probably 0 bytes and there’s no ._foo data file hiding there. Let’s now reference its fork with the phony “/rsrc” suffix on the datafile itself.
ls -l ~/Desktop/foo/rsrc
Now that you see > 0 bytes, we can crudely dump the text in the fork:
strings ~/Desktop/foo/rsrc
You should see some text. And to prove that foo is a data file and not a masquerading directory like apps are, we can verify:
file ~/Desktop
file ~/Desktop/foo
file /Library/Mail.app
It should say ‘directory’, ‘file’, ‘directory’. Now of course, outside the HFS-aware space, OS X would export that clipping strangely as ._foo or something, but clippings and urls are pure resource fork… plenty of files can do w/out the the fork data just fine. Hopefully someday they’ll be phased out entirely. =)
Spencer, Spencer, Spencer,
Don’t support what scenario? Writing files across different filesystems? Writing files from NFS to HFS? Keeping home accounts on NFS shares? This is built in to Mac OS X Server. It’s one of the two clickable options in the Server Admin GUI for home account locations (the other being, of course, AFP). If they don’t explicitly support it, they certainly tacitly do. And, moreover, they absolutely should.
First of all, it’s not vanilla BSD code. Mac OS X is built on top of an Apple-derived variant of BSD. And the BSD code is not what I’m talking about anyway. I’m talking about the way the Finder handles files on non-HFS volumes. The Finder is decidedly not BSD.
But it states that there are multiple files (i.e. “some of these items”) on the source. Also, having multiple files on the destination that all have the same name with different case usage, which is how you explain the plural “items” in the alert would be impossible because HFS would not allow as it is not case-sensitive. So your explanation doesn’t fly.
Why not? Are you suggesting that the app (I assume you mean the Finder) can’t read the entire directory and must stop at the first conflict? I don’t think this is true, but if it is it’s yet another problem with the handling of this sort of conflict.
I don’t see his as a problem with the server. The server IS case-sensitive, and it is Mac OS X that is complaining, because Mac OS X (unfortunately) is not.
Yes, but that’s exactly what I was talking about, and you claimed that such a thing does not exist. I am talking about dragging a file from an NFS volume to an HFS volume. A file that was created on a Mac (in my case, downloaded from the internet) on an NFS volume will often have a dot-underscore file associated with it. Here is some Terminal output that demonstrates what I’m talking about:
._Google-MonthView.pdf
._hairline001.tga
._tandtv14.1.pdf
._test.mpg
Google-MonthView.pdf
hairline001.tga
response.rtf
tandtv14.1.pdf
test.mpg
Note the mpg file and it’s dot-underscore counterpart. This is what I think caused the alert to say “some of these items.” The actual file will cause the conflict, but since there is no dot-underscore file on the destination, it will not cause a conflict.
Yes, but if I recall correctly, in the early days of Mac OS X (when Macs started interacting with non-HFS volumes with much greater frequency) there was nothing that handled the resource fork on non-HFS. The dot-underscore solution came after the introduction of Mac OS X as a response to the need to continue to preserve resource forks across filesystems in many instances.
Unfortunately, last I checked, Final Cut Pro project files still need a resource fork. I don’t think anyone I know would call that minor.
Well, the original point was that the dot-underscore was there in my scenario, and was possibly causing the “some of these items” in the alert because the Mac wanted to copy both the file and the dot-underscore file. We can argue all day about the use of the dot-underscore file, but according to Apple it, “contains the resource fork of the original file.”
Yes, I have seen the dreaded “._DS_Store.” Oy! What a kludge!
Uh, wrong again. There *is* a ._foo, and it *contains all the data.* I think what you may not be getting here is that my home account lives on an NFS server, which is why I get the weird alert and why I have dot-underscore files everywhere.
Yes, I *am* outside the HFS space. Because I am on an NFS volume. That was precisely my point. Perhaps that is not entirely clear in the article. I am going to amend the article to make it very explicit that my home account — the source of the file copy in question here — is an NFS mount.
But I stand by my belief that Apple is handling this sort of case strangely, and more importantly in a way that would be exceptionally confusing to many users, when all they really need to do is handle it the same way the Finder handles HFS-to-HFS copies. There is no functional difference.
We seem to agree that the message — and Apple’s use of dot files in general — is confusing. I’m not sure why we’re arguing.
-systemsboy
I think Finder needs to let you know when the source volume has two files that will be mapped into a single file on the destination. The wording is definitely broken, but you need to know. What if you had:
makefile
Makefile
and they were different (god knows why, but I’ve seen this done: some idiot discovered that two different Make variants used different Makefiles in this case, and decided to “take advantage” of it).
I don’t know the best way to fix this, I’m not one of Apple’s UI experts, and you’re right that the wording is totally confusing. But I gotta agree with your other stalker there, treating this like HFS-HFS is just asking for a visit from the f-up fairy.
Yes, of course, I completely agree. And in such a case the wording would be challenging to come up with.
In my case, however, from the Finder’s perspective at least, I was only copying a single file (with dot-files, yes, but no one’s supposed to see those). And in such a case, where behaviorally and functionally there is no difference to the user (the options and outcomes are the same) I think Apple could reuse the wording.
But, as evidenced by the wording of that alert, it doesn’t seem Apple is too concerned with these edge cases. Whether they are or not they still have some work to do on all of this.
Thanks, BTW, for that stalker comment. Good stuff.
-systemsboy
Oh, and by wild coincidence, today’s lead story over at MacFixit reads:
“Invisible files with “._” prefix are created on some shared volumes and external disks”
-systemsboy
I was in a weird mood, and feeling creepy about having all these blogs checked into my delicious bookmarks, so I was having this “OMG I’m a stalker” moment.
See, this is why I write anonymously.
-systemsboy
> I’m not sure why we’re arguing.
Details were being glossed over… The discussion (I didn’t see it as argument) was just over the details.
> Don’t support what scenario?
They shun setting up case-sensitive NFS shares for use on insensitive HFS-based machines.
> The server IS case-sensitive, and it is Mac OS X that is complaining, because Mac OS X (unfortunately) is not.
FS != OS… Keep it case-sensitive on the server, configure NFS to be insensitive, it will munge the filenames and drop duplicates on the client’s machine. Most NFS servers can handle the name interpolation for you.
> I think what you may not be getting here is that my home account lives on an NFS server.
Bingo.
> Thanks, BTW, for that stalker comment. Good stuff.
Wow, and with that, this is not the blog for me. =( I stumbled by while Googling for something else. I liked what I saw and added the RSS feed and decided to comment. So I guess people need to know you first beforehand. Weren’t public blogs and open comment systems meant for connecting strangers with common interests? It’s a rhetorical question.
> See, this is why I write anonymously.
That raises red flags with some people.
And don’t worry, no need to reply, I’m on my way.