From: lhall AT rfk DOT com (Larry Hall) Subject: Re: smtp mail failed 16 Oct 1998 13:38:37 -0700 Message-ID: <3.0.5.32.19981015165202.00aa32f0.cygnus.gnu-win32@pop.ma.ultranet.com> References: <199810141617 DOT KAA04778 AT chorus DOT dr DOT lucent DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "139a80000-HallM(DR3132)37x10" , gnu-win32 AT cygnus DOT com At 10:17 AM 10/14/98 -0600, 139a80000-HallM(DR3132)37x10 wrote: > >> As I've stated on my web pages under my Personal Reflections on this >> subject, IF YOU DEPEND ON THE BINARY MODE MOUNT SETTING THEN YOU ARE >> MASKING A PROBLEM WHICH WILL EVENTUALLY BYTE YOU SOMEWHERE ELSE. >> Consider yourself bytten. >> >> I suggest that you get the source code and find all of the open/fopen >> statements and properly add the necessary file mode processing >> switches. The only truly way to get rid of this for good is to >> properly port the code and be specific about what mode your file >> should be processing in. >> >> PORTERS OF SOFTWARE, please, don't depend on the binary mode mount >> setting!! Make the appropriate changes to the open/fopen statements. > >While I agree 100% with this view, there are some difficulties that are >particularly apparent with archive software. If tar is unpacking a file, >(or packing it, for that matter) is it a binary file or a text file? >Somehow, tar/zip/whatever must find out whether to open the file in text >or binary mode, yet there seems to be no definitive way to tell which. >Do you try to see if the file has all characters < 0x100 and line breaks >every so often to call it a text file? What about various meta-character >escapes (for extended character sets, bold/italic/underline, etc.). What >if an executable file actually does contain '\n' every so often. These >heuristics are bound to make mistakes, but what better way is there to >tell? > >marcus hall I think not, judging by what most applications I've seen do in this situation. The best examples of this are programs like FTP. These leave it up to the user to determine what mode they want to have files transferred in. You'll notice some clients default to text mode on DOS based machines and binary on UNIX machines (this could simply be an artifact of how they are built and may not be the result of something more sophisticated like checking the system type). Windows likes the idea of every file having an extension and inferring things based on this. I won't go into my personal view of this "convention" but it would, I suppose, be possible to make some inferences on the desired mode based on these designations as well. But its all heuristics if you want to attempt something automatic. As such, in my view, the case you describe with making some kind of archive file breaks down into 2 parts: what mode to use to make the archive and what mode to extract files. In my opinion, binary is always preferred when generating the archive. I would also submit that binary is preferred when extracting the file, since at least the Win32 platform file handling APIs now read binary file line endings as such, even when binary mode is not explicitly designated. This translates into all recently built software programs with the notable exception of Notepad (I wonder why that is...) Anyway, how the files are extracted is probably best left as a user preference (note that WinZip and a few other utilities like it have exactly such an option). So if in doubt, my opinion is don't bother trying to make a guess. At least for tools that need to be compatible in the Win32 and UNIX worlds, do everything in binary or leave the option up to the user. Note that the first option still probably falls under the category of a heuristic though... Larry Hall lhall AT rfk DOT com RFK Partners, Inc. (781) 239-1053 8 Grove Street (781) 239-1655 - FAX Wellesley, MA 02482-7797 http://www.rfk.com - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".