Tsntp ( attachments )
- Rick Lipkin
- Posts: 2397
- Joined: Fri Oct 07, 2005 1:50 pm
- Location: Columbia, South Carolina USA
Tsntp ( attachments )
Antonio
Just found some strange behavior in the tsmtp class .. I have a folder on our web server that has domain READ rights for our Agency. My executable launches from that domain folder
\\webdev\pmo\pmow32.exe
I have a file I wish to attach
c:\dbtmp\projinfo.bat
When a user runs the program and the application attaches c:\dbtmp\projinfo.bat .. the file gets delivered with zero bytes. What is strange is that when I run the application and the program sends the same attachment .. the message gets delivered with the attachment intact.
What I have deduced is that I have full rights to the \\webdev\pmo folder and regular users do not ( which is the way I want it ) .. I can send the attachments and they arrive, but no one else can. My guess is the tsmtp is copying the c:\dbtmp\projinfo.txt file to the exe location and since no one has rights there .. the file gets created with zero bytes and gets delivered that way.
I have been going crazy over this ... is there a way you can look at the class and see what is happening there .. does the attachment have to reside or does it get copied to the exe location in order to be sent ??
Is the attachment flowing theu a socket from the executable ?? This mystery definitly has to do with permissions in the executable folder..
Any hints or clues ?? .. ps, this is not a virus stripping issue .. it has been turned off.
Rick Lipkin
SC Dept of Health, USA
Here is the code snipit ..
// create the attachment on the local hard drive //
FERASE( "C:\DBTMP\PROJINFO.BAT")
cTEXT := "@ECHO OFF"+CHR(13)+CHR(10)
cTEXT += "echo Starting the PMO Strategic Projects Vital Signs Program"+CHR(13)+CHR(10)
cTEXT += cLINK+" /projecteid="+oRsproj:Fields("projecteid"):Value+CHR(13)+CHR(10)
nHANDLE := FCREATE( "C:\DBTMP\PROJINFO.BAT", 0 )
IF FERROR() <> 0
SAYING := "Error Creating file C:\DBTMP\ProjInfo.BAT"+CHR(10)
SAYING += "Error "+STR(FERROR())+CHR(10)
MsgInfo( SAYING )
ENDIF
FWRITE( nHANDLE, cTEXT ) // write out the file
FCLOSE( nHANDLE )
SysReFresh()
oWndMdi:SetMsg( "Sending Project ADD noticication to "+cTO )
WSAStartup()
oOutMail := TSmtp():New( cIP := GetHostByName( cHOST ) )
oOutMail:bConnecting = { || oWndMdi:SetMsg( "Connecting to "+cHOST ) }
oOutMail:bConnected = { || oWndMdi:SetMsg( "Connected" ) }
oOutMail:bDone = { || oWndMdi:SetMsg( "Message sent successfully" ) }
oOutMail:SendMail( cFROM,; // From
{ cTO },; //, cPMOEMAIL, cSPOEMAIL },; // To
cMESSAGE,; // Msg Text
cSUBJECT,;
{"C:\DBTMP\PROJINFO.BAT"},; // attachment
{ cSPOEMAIL, cPMOEMAIL }, ; // cc
{ }, ; // bc
.F., ; // no return receipt
NIL ) // not html
SysReFresh()
Just found some strange behavior in the tsmtp class .. I have a folder on our web server that has domain READ rights for our Agency. My executable launches from that domain folder
\\webdev\pmo\pmow32.exe
I have a file I wish to attach
c:\dbtmp\projinfo.bat
When a user runs the program and the application attaches c:\dbtmp\projinfo.bat .. the file gets delivered with zero bytes. What is strange is that when I run the application and the program sends the same attachment .. the message gets delivered with the attachment intact.
What I have deduced is that I have full rights to the \\webdev\pmo folder and regular users do not ( which is the way I want it ) .. I can send the attachments and they arrive, but no one else can. My guess is the tsmtp is copying the c:\dbtmp\projinfo.txt file to the exe location and since no one has rights there .. the file gets created with zero bytes and gets delivered that way.
I have been going crazy over this ... is there a way you can look at the class and see what is happening there .. does the attachment have to reside or does it get copied to the exe location in order to be sent ??
Is the attachment flowing theu a socket from the executable ?? This mystery definitly has to do with permissions in the executable folder..
Any hints or clues ?? .. ps, this is not a virus stripping issue .. it has been turned off.
Rick Lipkin
SC Dept of Health, USA
Here is the code snipit ..
// create the attachment on the local hard drive //
FERASE( "C:\DBTMP\PROJINFO.BAT")
cTEXT := "@ECHO OFF"+CHR(13)+CHR(10)
cTEXT += "echo Starting the PMO Strategic Projects Vital Signs Program"+CHR(13)+CHR(10)
cTEXT += cLINK+" /projecteid="+oRsproj:Fields("projecteid"):Value+CHR(13)+CHR(10)
nHANDLE := FCREATE( "C:\DBTMP\PROJINFO.BAT", 0 )
IF FERROR() <> 0
SAYING := "Error Creating file C:\DBTMP\ProjInfo.BAT"+CHR(10)
SAYING += "Error "+STR(FERROR())+CHR(10)
MsgInfo( SAYING )
ENDIF
FWRITE( nHANDLE, cTEXT ) // write out the file
FCLOSE( nHANDLE )
SysReFresh()
oWndMdi:SetMsg( "Sending Project ADD noticication to "+cTO )
WSAStartup()
oOutMail := TSmtp():New( cIP := GetHostByName( cHOST ) )
oOutMail:bConnecting = { || oWndMdi:SetMsg( "Connecting to "+cHOST ) }
oOutMail:bConnected = { || oWndMdi:SetMsg( "Connected" ) }
oOutMail:bDone = { || oWndMdi:SetMsg( "Message sent successfully" ) }
oOutMail:SendMail( cFROM,; // From
{ cTO },; //, cPMOEMAIL, cSPOEMAIL },; // To
cMESSAGE,; // Msg Text
cSUBJECT,;
{"C:\DBTMP\PROJINFO.BAT"},; // attachment
{ cSPOEMAIL, cPMOEMAIL }, ; // cc
{ }, ; // bc
.F., ; // no return receipt
NIL ) // not html
SysReFresh()
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Rick,
I don't know the answer, but have you tried creating the file in a directory where the user has all rights just to see if it works that way?
I don't think a temporary copy is created in the dir of the exe as I had to go to some effort to create temp files, wait for them to be sent, then delete them afterward. If the class was creating its own temp file, then I wouldn't have had this problem.
James
I don't know the answer, but have you tried creating the file in a directory where the user has all rights just to see if it works that way?
I don't think a temporary copy is created in the dir of the exe as I had to go to some effort to create temp files, wait for them to be sent, then delete them afterward. If the class was creating its own temp file, then I wouldn't have had this problem.
James
- Rick Lipkin
- Posts: 2397
- Joined: Fri Oct 07, 2005 1:50 pm
- Location: Columbia, South Carolina USA
James
YES .. that is what lead me to my conclusion .. I moved the .exe to the users desktop and it worked perfectically .. same program. It has something to do with ( I think ) the file flowing thru the application ?? sounds silly I know. I know tsmtp uses a windows tsocket .. so it is tangled up with the application somehow.
Rick
YES .. that is what lead me to my conclusion .. I moved the .exe to the users desktop and it worked perfectically .. same program. It has something to do with ( I think ) the file flowing thru the application ?? sounds silly I know. I know tsmtp uses a windows tsocket .. so it is tangled up with the application somehow.
Rick
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
- Rick Lipkin
- Posts: 2397
- Joined: Fri Oct 07, 2005 1:50 pm
- Location: Columbia, South Carolina USA
James
I actually used the tsmtp class you sent me some time ago .. and I contributed it to Antonio which he included in 8.07.
That version is the one I am using and it works quite well .. as far as the .txt .. I did that and it made no difference in the attachment being delivered .. zero bytes.. However, if I am running the program with my login ( have full folder control over \\webdev\pmo ) .. the attachment is delivered intact.
Again, I tested this with another user .. with a .txt and .bat and the user who was logged in running my program from \\webdev\pmo failed. But, move the same folder to his desktop .. and it works perfectically.. so it has something to do with permissions or perhaps running the program from a unc and smtp ??
Rick
I actually used the tsmtp class you sent me some time ago .. and I contributed it to Antonio which he included in 8.07.
That version is the one I am using and it works quite well .. as far as the .txt .. I did that and it made no difference in the attachment being delivered .. zero bytes.. However, if I am running the program with my login ( have full folder control over \\webdev\pmo ) .. the attachment is delivered intact.
Again, I tested this with another user .. with a .txt and .bat and the user who was logged in running my program from \\webdev\pmo failed. But, move the same folder to his desktop .. and it works perfectically.. so it has something to do with permissions or perhaps running the program from a unc and smtp ??
Rick
SMTP
Rick,
We resolved that several months ago. Let me check my notes because I have it somewhere here. Its a quick modification to the class.
Tim
We resolved that several months ago. Let me check my notes because I have it somewhere here. Its a quick modification to the class.
Tim
Tim Stone
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
Solution
Here is the problem. When you create the temporary file, it is local, but when you use oSocket:SendFile, it uses the default path.
Here is the solution. Make this change in your code:
Static Function TmpFile()
Local cTmpDir := GetEnv( "TEMP" ) + "\" // LK Mar/26/2008 added path to avoid file being created in _SET_DEFAULT directory Local cTmpName := "__temp"
Do While File( cTmpName := cTmpDir + "__" + StrZero( nRandom( 99999 ), 5
) + ".tmp" )
Enddo
FClose( FCreate( cTmpName ) )
Luis Krause Mantilla made this change after I isolated the problem. I have my own path variable so I had just used that method. My problem was identical to yours but once I made this fix, I've never had a problem again.
Tim
Here is the solution. Make this change in your code:
Static Function TmpFile()
Local cTmpDir := GetEnv( "TEMP" ) + "\" // LK Mar/26/2008 added path to avoid file being created in _SET_DEFAULT directory Local cTmpName := "__temp"
Do While File( cTmpName := cTmpDir + "__" + StrZero( nRandom( 99999 ), 5
) + ".tmp" )
Enddo
FClose( FCreate( cTmpName ) )
Luis Krause Mantilla made this change after I isolated the problem. I have my own path variable so I had just used that method. My problem was identical to yours but once I made this fix, I've never had a problem again.
Tim
Tim Stone
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Tim,
I am confused. Is the function tmpFile() part of your TSMTP.PRG? I don't have it in mine.
Also, when is it used? Rick is creating his own file and it is not a temp file and he is including the path, so it seems he should not be having the same problem that you were, unless the SMTP class is automatically creating a temp file copy of the attachment.
James
I am confused. Is the function tmpFile() part of your TSMTP.PRG? I don't have it in mine.
Also, when is it used? Rick is creating his own file and it is not a temp file and he is including the path, so it seems he should not be having the same problem that you were, unless the SMTP class is automatically creating a temp file copy of the attachment.
James
- Rick Lipkin
- Posts: 2397
- Joined: Fri Oct 07, 2005 1:50 pm
- Location: Columbia, South Carolina USA
SMTP
I'm using the SMTP extension to the FWH class. Louis provided this extension a number of years ago.
In the OnRead( ) method, at least in my version, there is an oSocket:SendData( ) operation for including attachments. Here is the code snippet:
For nI := 1 To Len( ::aFiles )
If File( ::aFiles[ nI ] )
cExt := Upper( cFileExt( ::aFiles[ nI ] ) )
If ( cExt == "TXT" .or. cExt == "LOG" .or. cExt == "HTM" ) .and. ! ::lTxtAsAttach
oSocket:SendData( CRLF + "--NextPart" + CRLF + ;
"Content-Type: " + DocType( cExt ) + ;
'name="' + ::aFiles[ nI ] + '"' + CRLF + ;
"Content-Transfer-Encoding: " + If( cExt == "HTM", "7bit", "quoted-printable" ) + CRLF + ;
"Content-Disposition: inline; " + ; // LKM was attachment
'filename="' + cFileNoPath( ::aFiles[ nI ] ) + '"' + CRLF + CRLF )
oSocket:SendFile( ::aFiles[ nI ],, ::nDelay )
Else
oSocket:SendData( CRLF + "--NextPart" + CRLF + ;
"Content-Type: " + DocType( cExt ) + ;
'name="' + ::aFiles[ nI ] + '"' + CRLF + ;
"Content-Transfer-Encoding: base64" + CRLF + ;
"Content-Disposition: attachment; " + ; // LKM was inline
'filename="' + cFileNoPath( ::aFiles[ nI ] ) + '"' + CRLF + CRLF )
cTmpFile := TmpFile() // ivt (based on his fix)
FMimeEnc( ::aFiles[ nI ], cTmpFile )
oSocket:SendFile( cTmpFile,, ::nDelay )
FErase( cTmpFile )
Endif
Endif
Next
The problem was that the system created the temporary file locally, but when trying to send it, it looked to the default directory. So the previous fix is the function you see needed here ( cTmpFile := TmpFile( ) )
If you are using the older SMTP with FWH, then you may find a similar spot in the code where this problem is occuring.
Now, I realize none of this makes sense ... it shouldn't store the file one place and look for it somewhere else ... but it does ! Anyway the problem was totally consistent and this totally fixed it.
Tim
In the OnRead( ) method, at least in my version, there is an oSocket:SendData( ) operation for including attachments. Here is the code snippet:
For nI := 1 To Len( ::aFiles )
If File( ::aFiles[ nI ] )
cExt := Upper( cFileExt( ::aFiles[ nI ] ) )
If ( cExt == "TXT" .or. cExt == "LOG" .or. cExt == "HTM" ) .and. ! ::lTxtAsAttach
oSocket:SendData( CRLF + "--NextPart" + CRLF + ;
"Content-Type: " + DocType( cExt ) + ;
'name="' + ::aFiles[ nI ] + '"' + CRLF + ;
"Content-Transfer-Encoding: " + If( cExt == "HTM", "7bit", "quoted-printable" ) + CRLF + ;
"Content-Disposition: inline; " + ; // LKM was attachment
'filename="' + cFileNoPath( ::aFiles[ nI ] ) + '"' + CRLF + CRLF )
oSocket:SendFile( ::aFiles[ nI ],, ::nDelay )
Else
oSocket:SendData( CRLF + "--NextPart" + CRLF + ;
"Content-Type: " + DocType( cExt ) + ;
'name="' + ::aFiles[ nI ] + '"' + CRLF + ;
"Content-Transfer-Encoding: base64" + CRLF + ;
"Content-Disposition: attachment; " + ; // LKM was inline
'filename="' + cFileNoPath( ::aFiles[ nI ] ) + '"' + CRLF + CRLF )
cTmpFile := TmpFile() // ivt (based on his fix)
FMimeEnc( ::aFiles[ nI ], cTmpFile )
oSocket:SendFile( cTmpFile,, ::nDelay )
FErase( cTmpFile )
Endif
Endif
Next
The problem was that the system created the temporary file locally, but when trying to send it, it looked to the default directory. So the previous fix is the function you see needed here ( cTmpFile := TmpFile( ) )
If you are using the older SMTP with FWH, then you may find a similar spot in the code where this problem is occuring.
Now, I realize none of this makes sense ... it shouldn't store the file one place and look for it somewhere else ... but it does ! Anyway the problem was totally consistent and this totally fixed it.
Tim
Tim Stone
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
- Rick Lipkin
- Posts: 2397
- Joined: Fri Oct 07, 2005 1:50 pm
- Location: Columbia, South Carolina USA
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
- Rick Lipkin
- Posts: 2397
- Joined: Fri Oct 07, 2005 1:50 pm
- Location: Columbia, South Carolina USA
Tim
I have some doubts about the TmpFile() function .. I do not see the end of the loop and should the function return( cTmpName ) ??
I presume the variable cTmpFile := TmpFile() .. cTmpFile should be declared as local ??
Rick Lipkin
ps .. james .. I have gone 'nuts' with this and the attachment piece is the real krux of this application. Glad I could make you smile
//----------------------------------------------------------------------------//
Static Function TmpFile()
Local cTmpDir := GetEnv( "TEMP" ) + "\" // LK Mar/26/2008 added path to avoid file being created in _SET_DEFAULT directory Local cTmpName := "__temp"
Do While File( cTmpName := cTmpDir + "__" + StrZero( nRandom( 99999 ), 5 ) + ".tmp" )
Enddo
FClose( FCreate( cTmpName ) )
// return( ???? )
I have some doubts about the TmpFile() function .. I do not see the end of the loop and should the function return( cTmpName ) ??
I presume the variable cTmpFile := TmpFile() .. cTmpFile should be declared as local ??
Rick Lipkin
ps .. james .. I have gone 'nuts' with this and the attachment piece is the real krux of this application. Glad I could make you smile
//----------------------------------------------------------------------------//
Static Function TmpFile()
Local cTmpDir := GetEnv( "TEMP" ) + "\" // LK Mar/26/2008 added path to avoid file being created in _SET_DEFAULT directory Local cTmpName := "__temp"
Do While File( cTmpName := cTmpDir + "__" + StrZero( nRandom( 99999 ), 5 ) + ".tmp" )
Enddo
FClose( FCreate( cTmpName ) )
// return( ???? )
Nutty Hair
Its too late for the Rogaine for me ...
I may have cut off the code on the first post but I sent you the complete files ...
If you look at this board you will see I posted here, and on the newsgroups, several threads about this problem. Finally I just started isolating the problem and then went back to Luis when I found the root cause and a solution. He provided a cleaner solution then mine.
Its frustrating because it doesn't make sense ... and a while back it worked OK without the modifications. However an update to xHarbour apparently made the change necessary. I fixed it finally late last year.
Tim
I may have cut off the code on the first post but I sent you the complete files ...
If you look at this board you will see I posted here, and on the newsgroups, several threads about this problem. Finally I just started isolating the problem and then went back to Luis when I found the root cause and a solution. He provided a cleaner solution then mine.
Its frustrating because it doesn't make sense ... and a while back it worked OK without the modifications. However an update to xHarbour apparently made the change necessary. I fixed it finally late last year.
Tim
Tim Stone
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
- Rick Lipkin
- Posts: 2397
- Joined: Fri Oct 07, 2005 1:50 pm
- Location: Columbia, South Carolina USA