<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
My goodness varying file system, OS file system support, network file system protocol feature sets, character encodings, case sensitivity rules, is a rats of nest of subtle but significant problems even if you are developing on one OS and/or one file system..<BR>
<BR>
On my Mac I have file names with forward slashes and question marks (I didn't create them, they were downloaded that way, such as the MPW SC/SCpp reference and "Where is JBindery?"). I can't copy them to my low end Linux NAS.<BR>
<BR>
The source to the low end Linux NAS has dots at the start of some file names. It cannot be copied over itself from Windows, because such files are hidden and cannot be unhidden.<BR>
<BR>
Here's a tidbit -- Windows has "long" file names and "short" file names. Guess which is longer?<BR>
Try this:<BR>
cd \<BR>
mkdir "1.1.1" <BR>
dir /x 1* <BR>
<BR>
Short names can be around twice as long as long names, at least. Anything with two dots, or Unicode I believe, needs a generated short name, even if it isn't particulary long. Short names these days tends to get more randomness in them I think, for security..<BR>
<BR>
Also the wildcard matching is unpredictable due to generated short names.<BR>
mkdir foo.1234 <BR>
dir *.123 <BR>
<BR>
That probably matches, but can't say for sure.<BR>
<BR>
And still I trust NTFS more than anything else. :)<BR>
<BR>
- Jay<BR>
<BR>> Date: Sun, 14 Oct 2007 14:56:54 +0200<BR>> From: stsp@elego.de<BR>> To: rodney.bates@wichita.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Pathname.Legal<BR>> <BR>> On Sun, Oct 14, 2007 at 06:11:49AM -0500, Rodney M. Bates wrote:<BR>> > Since the language itself specifies that program variables of type<BR>> > CHAR are in ISO Latin-1, not just ASCII, I think extending compilers,<BR>> > etc., to handle those characters makes complete sense, without even<BR>> > needing to view it as support for unicode or differing locales.<BR>> ><BR>> > Do I understand correctly that Neels' patch extends just to ISO Latin-1?<BR>> <BR>> More than that. The patch allows any byte-sized character<BR>> except the DirSepChar, which effectivly makes any character<BR>> encoding that uses single byte encoding legal.<BR>> <BR>> So Latin-2 etc. are also included, which is a feature,<BR>> not a bug. As long as only single byte encodings are involved<BR>> this is totally fine.<BR>> <BR>> So since CM3 assumes Latin-1 anyway, not handling unicode correctly<BR>> is not a problem. But users should be made aware that if they<BR>> use CM3 programs with filenames in multi-byte encodings such<BR>> as UTF-8, really strange things may happen...<BR>> <BR>> CM3 should get unicode support some day... unicode is quite hairy,<BR>> I've seen quite a few UTF-8 related problems in the subversion bug<BR>> tracker. Subversion tries to use UTF-8 all the way.<BR>> <BR>> The problems were along the lines of using either<BR>> 'this an a with umlaut;',<BR>> or 'the next char has an umlaut; a;',<BR>> or 'a; the previous char had an umlaut;'<BR>> for encoding the ä character. These are all legal UTF-8.<BR>> <BR>> But: The encoding method used on a given system is up to the<BR>> filesystem implementation in the OS, i.e. hard to detect.<BR>> So in case of subversion, which does not heed all these cases (yet),<BR>> filenames with umlauts work on UNIX and Windows, but not on MacOSX.<BR>> Wheeee! :)<BR>> <BR>> -- <BR>> Stefan Sperling <stsp@elego.de> Software Developer<BR>> elego Software Solutions GmbH HRB 77719<BR>> Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 <BR>> 13355 Berlin Fax: +49 30 23 45 86 95<BR>> http://www.elego.de Geschaeftsfuehrer: Olaf Wagner<BR><BR><br /><hr />Windows Live Hotmail and Microsoft Office Outlook – together at last. <a href='http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033' target='_new'>Get it now!</a></body>
</html>