[X-Unix] Re: Unlinking a file... illegal characters?

[William H. Magill]

On 27 Feb, 2005, at 10:14, James Bucanek wrote:
> I've been watching everyone thrash around on this for a bit, and have 
> a couple of suggestions:
>
> (1) Is the original poster sure that the volume isn't damaaged?  I'd 
> start up in single user mode and run fsck before continuing.
>
> (2) I suspect that the problem is Unicode.  Most C/Perl/whatever 
> programs are going to be using the C interfaces to the BSD file 
> services.  There are some subtle complications between that layer, 
> which works with UNIX paths as C strings, and the Carbon layer, which 
> uses Unicode, where the HFS filesystem is actually implemented.  For 
> instance, there are Unicode character sequences which can't be 
> preserved through translation, not even using UTF-8.  That is to say, 
> OriginalUnicode->UTF-8->Unicode != OriginalUnicode.
>
> If that assumption is true, there are no UNIX level tools that are 
> going to let you delete this file.  Heck, there probably aren't any 
> UNIX level tools that can even tell you what its exact name is.  Note 
> that this is not the first time this has happened.  I filed a bug 
> against OS 10.1 where a StuffIt archive was unpacked on OS X creating 
> two files named (I kid you not) "." and "..".  These were impossible 
> to delete in OS X.

Assuming that the problem is not 1 above, this then is clearly the 
problem. What I was alluding to in my earlier comment about using 
emacs:
      "Since this is "legoland" something, I would assume that
       the file name is full of "foreign" (Danish) characters
       encoded via something other than utf-8."

The fact that emacs fails to deal with the file pretty much verifies 
the Unicode issue.

> What you need is a Carbon application to delete this file.  My 
> suggestion would be to reverse the process.  You've got an archive 
> that created this filename -- use StuffIt or something to delete it.  
> Select the enclosing folder and tell StuffIt to create an archive and 
> delete the original.  My guess is that StuffIt will use the Carbon 
> APIs, get the Unicode version of the filename (or, more likely, its 
> FSRef), and delete it with no muss or fuss.

Hmmm ... sounds like a good trick!

... I deleted the original some time ago, but yesterday,

On 26 Feb, 2005, at 06:11, Stroller wrote:
> It's part of a big back-up of a customer's PeeCee, the rest of which 
> was zipped, burned to DVD & deleted. It was originally in "Program 
> Files", and I'm sure that this is just some file from the installation 
> of one of the Lego-branded computer games. Since I regularly back-up 
> PCs' whole C: drives to my portable drive by booting to a Linux liveCD 
> & using `cp -Rvf ...` many thousands of files might be copied on & off 
> this drive each week - my guess is simple filesystem corruption.

So, one question is -- how did this file get to OS X in the first place?

Apparently by way of Linux, not from a zip file.

So this was this a Linux kernel writing to a Mac OS X volume?
A "ufs" volume being shared between two different operating systems?

Either technique should scream "potential incompatibility" leading to 
"filesystem corruption."

How about using the Linux Live CD to delete the file?

T.T.F.N.
William H. Magill
# Beige G3 [Rev A motherboard - 300 MHz 768 Meg] OS X 10.2.8
# Flat-panel iMac (2.1) [800MHz - Super Drive - 768 Meg] OS X 10.3.7
# PWS433a [Alpha 21164 Rev 7.2 (EV56)- 64 Meg] Tru64 5.1a
# XP1000  [Alpha 21264-3 (EV6) - 256 meg] FreeBSD 5.3
# XP1000  [Alpha 21264-A (EV 6.7) - 384 meg] FreeBSD 5.3
magill at mcgillsociety.org
magill at acm.org
magill at mac.com
whmagill at gmail.com