This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: smtp mail failed


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@rfk.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@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]