<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">--I tried sending this on the bug report thread but got a delivery failure notice --<div><br></div><div><br></div><div>Robert, Laurence and Alexandre -<div><br></div><div>Thanks for the feedback on this issue. Here are my thoughts on further investigation.</div><div><br></div><div>Since ft_preprocessing calls its own ft_read_header (ft_preprocessing:327), ft_read_event isn't actually going for data, and that ft_definetrial and ft_preprocessing are separate high-level functions, then I think we can assume that no actual data will be read during ft_read_event and the file can be closed towards the end of the ft_read_event function. That closes one leak.</div><div><br></div><div>Because ft_preprocessing is one of the high-level functions of FT and that the function is structured to operate on the data file once per event, it should clean up anything it opened.  It'd be simple enough to check if hdr.orig.raw.fid is still open after all the data reading has been done (after ft_preprocessing:530) and close it.  This way, you wouldn't have to fundamentally change how ft_read_data operates on neuromag files. I'm not sure how the architecture of FT deals with other file formats and whether this is sort of leak can occur in other situations, but this seems to be the easiest fix to this problem.</div><div><br></div><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Scott Burns</div><div>Kuperberg Lab</div><div>Martinos Center for Biomedical Imaging</div><div><a href="mailto:sburns@nmr.mgh.harvard.edu">sburns@nmr.mgh.harvard.edu</a></div><div><br></div><div><span class="Apple-style-span" style="border-collapse: collapse; "><font class="Apple-style-span" face="Arial" size="1"><span class="Apple-style-span" style="font-size: 9px; ">The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at </span></font><a href="http://www.partners.org/complianceline" target="_blank"><font class="Apple-style-span" face="Arial" size="1"><span class="Apple-style-span" style="font-size: 9px; "><font class="Apple-style-span" color="#000000">http://www.partners.org/<wbr>complianceline</font></span></font></a><font class="Apple-style-span" face="Arial" size="1"><span class="Apple-style-span" style="font-size: 9px; "> . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.</span></font></span></div><div><br></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On Feb 9, 2011, at 1:16 PM, Alexandre Gramfort wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>hi,<br><br><blockquote type="cite">I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file).<br></blockquote><br>ok. That was a quick and dirty hack to give an idea.<br><br><blockquote type="cite">So we need to store the cursor position too. See my earlier e-mail.<br></blockquote><br>maybe you or scott can propose a fix in the same vein?<br><br>I can give you write access to the mne-matlab code if you want.<br><br>Alex<br><br><br></div></blockquote></div><br></div></body></html>