|
SA Bugzilla – Full Text Bug Listing |
Summary: | MISSING_HB_SEP on all messages using WIN32 and Cygwin | ||
---|---|---|---|
Product: | Spamassassin | Reporter: | Fred T <tech2> |
Component: | Rules | Assignee: | SpamAssassin Developer Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P5 | ||
Version: | SVN Trunk (Latest Devel Version) | ||
Target Milestone: | Undefined | ||
Hardware: | Other | ||
OS: | Windows XP | ||
Whiteboard: | |||
Attachments: |
Sample message with issue
Debug of message channel Second sample message |
Description
Fred T
2007-01-24 14:27:44 UTC
We would definitely need a sample. Created attachment 3839 [details]
Sample message with issue
Created attachment 3840 [details]
Debug of message channel
Here's a debug of the channel "message" when I run -t -Dmessage on this
message, it's showing a problem with Message/Node.pm
[3908] warn: seek() on closed filehandle $tmpfile at
C:\Perl\site\lib/Mail/SpamA
ssassin/Message/Node.pm line 273.
Created attachment 3841 [details]
Second sample message
Hrm. I can't reproduce the missing separator bit, but the seek/read errors are from parts which 3.2 tries storing in temp files. Does Windows auto-close file handles which are open to files that get deleted? ie: open(FOO, "+>foo"); unlink "foo"; is "*FOO" now refering to a closed file? If so, we'll have to tack in a "am I running on windows" check in Message::parse_normal() and skip this behavior. (In reply to comment #5) > Hrm. I can't reproduce the missing separator bit, but the seek/read errors are > from parts which 3.2 tries storing in temp files. Does Windows auto-close file > handles which are open to files that get deleted? ie: > > open(FOO, "+>foo"); > unlink "foo"; > > is "*FOO" now refering to a closed file? If so, we'll have to tack in a "am I > running on windows" check in Message::parse_normal() and skip this behavior. Looking at "perldoc perlport", it might do: Some platforms can't delete or rename files held open by the system, this limitation may also apply to changing filesystem metainformation like file permissions or owners. Remember to "close" files when you are done with them. Don't "unlink" or "rename" an open file. Don't "tie" or "open" a file already tied or opened; "untie" or "close" it first. the source of File::Temp says: # internal routine to determine whether unlink works on this # platform for files that are currently open. # Returns true if we can, false otherwise. # Currently WinNT, OS/2 and VMS can not unlink an opened file # On VMS this is because the O_EXCL flag is used to open the # temporary file. Currently I do not know enough about the issues # on VMS to decide whether O_EXCL is a requirement. sub _can_unlink_opened_file { if ($^O eq 'MSWin32' || $^O eq 'os2' || $^O eq 'VMS' || $^O eq 'dos' || $^O eq 'Ma cOS') { return 0; } else { return 1; } } Fred, could you try current SVN trunk? r499012 may help. That was it! The MISSING_HB_SEP is no longer hitting on the samples I submitted. |