Intrafoundation Software
Making Atomic Warfare Fun Again
News & Forums Active Projects Queued Projects | War & Politics God Cryptography Operating Systems Game Development | Writings Poetry Film Making Wisdom | ColdFusion ASP COM Objects Javascript Web Design Java | Photography Raytracing DOS Software

| Need a shoulder to cry on while trying to convince Windows to properly work with our software? Just want to chat about something related to the site? Feel free to use the forums slash news slash blog. (Unsolicited commercial spam will be deleted, obviously.) | Looking for something?

This is thread 135. The complete list of threads is available on the main forums page.

Subject: cfx_secfile "bug" in use of line termination characters Author: Bob Jacoby Date/Time: 3/24/2003 11:27:48 AM (135.0) cfx_secfile converts end of line characters to windows style upon writes. cffile doesn't. Since cfx_secfile is supposed to mirror the functionality of cffile I consider this a bug in cfx_secfile. For most cases this isn't a big deal, but for some it is (hashing for example). Is there a fix in the works? I havn't coded in C++ so can't fix this myself. Here's a cut and paste from a test page I wrote to show this in greater detail. It uses a login/password of test/test. You will need to create this login/password for your cfx_secfile and switch the dir variable in the below code if you want to run it in your local environment: ---------------------- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Testing the cfx_secfile tag</title> </head> <body> <cfoutput> <b>Intro</b> <br/> This page tests the functionality of the cfx_secfile tag for the read and write actions by comparing it to in-memory representation of the string to be written and the actions of cffile, which cfx_secfile is supposed to mirror. The test utilizes the CF hash function to uniquely identify a string (which includes all "hidden" characters such whitespace). <ol> <cfset dir = "c:\devenv\apache2\htdocs"> <li>Set a variable, stringA, to a test string 'A', that spans multiple lines.</li> <cfset stringA="What would you do for a"> <cfset stringA=stringA & " klondike bar?"> <i><pre>stringA=#stringA#</pre></i> <li>Take a hash of string 'A'. This is the control hash value. For a string 'B' to be considered the same as 'A' the hash of 'B' must be the same.</li> <i><pre>stringA Hash: #hash(stringA)#</PRE></i> <li>Use cfx_secfile to write the variable, stringA, to a file</li> <cfx_secfile USERNAME="test" PASSWORD="test" action="WRITE" file="#dir#\cfxwrite.xml" output="#stringA#" addnewline="No"> <i><pre>File written: #dir#\cfxwrite.xml</pre></i> <li>Use cfx_secfile to read the file written by cfx_secfile back to a variable</li> <cfx_secfile USERNAME="test" PASSWORD="test" action="read" file="#dir#\cfxwrite.xml" variable="CFXReadOfCFXWrite" > <i><pre>variable read=#CFXReadOfCFXWrite#</pre></i> <li>Take a hash of the read in variable and compare to the hash of string 'A'. Note: The hashes are different</li> <i><PRE>Hash of CFXReadOfCFXWrite=#hash(CFXReadOfCFXWrite)# is unequal to #hash(stringA)#</PRE></i> <li>Use cffile to read the file written by cfx_secfile in to a variable</li> <cffile action = "read" file = "#dir#\cfxwrite.xml" variable = "CFReadOfCFXWrite"> <i><PRE>variable read=#CFReadOfCFXWrite#</PRE></i> <li>Take a hash of the read in variable and compare to the hash of string 'A'. Note: The hashes are different, but this hash is the same as the hash of variable created by cfx_secfile when it read in the same file</li> <i><PRE> Hash of CFReadOfCFXWrite=#hash(CFReadOfCFXWrite)# is unequal to #hash(stringA)# </PRE></i> <li>Use cffile to write the variable, stringA, to a file</li> <cffile action = "write" file = "#dir#\cfwrite.xml" output = "#stringA#" addNewLine = "No" > <i><pre>File written: #dir#\cfwrite.xml</pre></i> <li>Use cfx_secfile to read the file written by cffile back to a variable</li> <cfx_secfile USERNAME="test" PASSWORD="test" action="read" file="#dir#\cfwrite.xml" variable="CFXReadOfCFWrite" > <i><PRE>variable read=#CFXReadOfCFWrite#</PRE></i> <li>Take a hash of the read in variable and compare to the hash of string 'A'. Note: The hashes are the same</li> <i><PRE>Hash of CFXReadOfCFWrite=#hash(CFXReadOfCFWrite)# is equal to #hash(stringA)#</PRE></i> <li>Use cffile to read the file written by cffile in to a variable</li> <cffile action = "read" file = "#dir#\cfwrite.xml" variable = "CFReadOfCFWrite"> <i><PRE>variable read=#CFReadOfCFWrite#</PRE></i> <li>Take a hash of the read in variable and compare to the hash of string 'A'. Note: The hashes are the same</li> <i><pre>Hash of CFReadOfCFWrite=#hash(CFReadOfCFWrite)# is equal to #hash(stringA)#</pre></i> </ol> <P> <b>Additional Info:</b> <br/> You now have 2 files written to disk. One was written by cffile, one was written by cfx_secfile. If you look at the files and view the whitespace you will notice that there are different line terminination characters at the end of the line. Researching further it appears CFFile writes the file with unix style line termination while cfx_secfile writes the file in windows style line termination. This is only relevant for writing to windows machines. I did not test and do not know what style cffile and cfx_secfile use to write to unix or other machines. In order to see this for yourself your text viewer must be able to show these differences, rather than automatically convert them to whatever system you're using. I used the BeyondCompare comparison tool. Word, wordperfect, and other editor tools were not able to show this. <br/><br/> To test my theory of line termination I used the program WS_FTP to convert the file written by cfx_secfile to unix style line termination. This file matched perfectly with what was written by cffile (including whitespace). To further test I read in the converted file using cfx_secfile and calculated the hash. It correctly reproduced the hash. This conclusively proves that differences in the line termination (specifically unix vs windows) is what is responsible for the hashing differences. <br/><br/> As a quick fix to converting the files I tried reading the files written by cfx_secfile and rewriting them using cffile. However, this does not work. CFFile preserves the style of the file read in. </P> <P> <b>Conclusion</b> <br> There are two possible conclusions based on your point of view: <br><br> 1. cfx_secfile incorrectly writes files to disk - at least for the windows system. It does not mirror the format of cffile or the in-memory representation of the string prior to writing. cfx_secfile does not meet the claim that it functionally mirrors cffile. I would like to see an attribute added to allow for writing to the various styles (unix, mac, windows, etc). <br><br> 2.cffile incorrectly writes files to a windows machine. It should convert the EOL symbol to that used for windows. I would like to see an additional attribute added to allow for writing to the various styles (unix, mac, windows, etc). <br><br> Regardless of where you feel the fault lies cfx_secfile does not meet the claim that it functionally mirrors cffile. Generally this isn't a big deal. However, it is a significant (and showstopper) difference when whitespace inconsistencies are a concern. For example, the current webSTEERS Copy of Record (COR) implementation uses cfx_secfile to write the COR to disk. Prior to writing to disk it takes a hash of the in-memory representation of the COR (stored in a variable). As shown during the above tests this hash can not be reproduced regardless of whether cffile or cfx_secfile is used to read the file back in. To reproduce the hash the written file must first be converted to unix style. </P> <P> Direct any questions or comments to Bob Jacoby </P> </body> </html> </cfoutput>
Subject: RE:cfx_secfile Author: Bob Jacoby Date/Time: 3/24/2003 11:30:37 AM (136.135) crap. Didn't realize it'd try and execute the cfm code I put in. But i think i named my variables decent enough for you to get the idea. If anyone wants the actual cfm file give me an email - rjacoby@tceq.state.tx.us and i'll send it to you. Thanks, Bob
Subject: RE:cfx_secfile Author: Lewis Sellers Date/Time: 3/28/2003 4:58:16 PM (140.135) It tried to execute it? ;-) Oh well. Was finally going to get around to converting the site to ASP next week anyway. (I'm wondering if it still emails a copy of all replies to everyone concerned as well now that you bring it up.) --min I'll see about adding an "attachment" feature while I'm at it.

| REPLY
--- | ---
Author: |
Subject: |
Your Message: |
Email: (optional) |

`(Note: For safety all HTML in your message text may be printed exactly as you typed it.)`
top