textscan overwriting files by accident

Hi all, I'm having a bit of a weird issue using textscan in my code. I have a script that reads in a text file that contains numbers and saves the data as a matrix. Normally this works without any issues but recently I have noticed that it stops reading in the file at a random point and overwrites some of the text with some of the actual script itself. This strikes me as a very strange error and I am wondering whether this is a problem with my code or perhaps with my hard drive instead. Here is the part of the script that is relevant:

        textFileName = ['particles-' sprintf('%d',((t-1)*interval)+start) '.test'];
        fid = fopen(textFileName, 'rt');
        if fid == -1

        else
            num = textscan(fid, '%s %s', 1, 'headerlines', 3);
            num = strjoin(num{1});
            num = sscanf(num,'%f');
            textscan(fid,'%s',6,'Delimiter','\n');
            particles = (fscanf(fid,'%f',[9 num]))';
            position = zeros(num,4);
            position(:,1:3) = particles(:,3:5);
            position(:,4) = particles(:,1);
        end

And here is a sample of the text file that has been partially overwritten:

386228 1 0.0662485 0.397051 0.344767 0.000712695 -0.00815022 -1.6027 -1.37594 
386217 1 0.0684037 0.396032 0.345112 0.000792697 -0.0592417 -1.58495 -1.42259 
387311 1 0.0674784 0.397102 0.345217 0.000581904 -0.0012856 -1.60761 -1.41591 
383016 1 0.0686809 0.39647 0.343355 0.000840379 -0.0227589 -1.5897 -1.34409 
386223 1 0.0699436 0.396461 0.344592 0.000869548 -0.0221801 -1.58447 -1.3753 
388374 1 0.0680458 0.39766 0.343961 0.000637218 -0.00400114 -1.57884 -1.36597 
355394 1 0.0667938 0.398342 0.34412 0.000797339 -0.0170712 -1.57003 -1.35341 
379120 1 0.0672106 0.399489 0.343552 0.000544651 -0.0272359 -1.55709 -1.33239 
381997 1 0.0675321 0.399287 0.344816 0.0005843 -0.0196108 -1.5518 -1.3685 
387303 1 0.0683333 0.398058 0.345214 0.000696598 -0.0160907 -1.59867 -1.34937 
356448 1 0.0669659 0.398461 0.345467 0.000561225 -0.00379626 -1.58401 -1.34752 
382004 1 0.0707067 0.397768 0.343918 0.00072654 -0.0176303 -1.5693 -1.34347 
387304 1 0.0693334 0.397877 0.344146 0.000658041 -0.00837573 -1.58017 -1.35183 
412793 1 0.0701707 0.398942 0.34345 0.000644702 -0.0270941 -t([1 1 1]);
% %             set(gcf,'Position',[100,100,1800,600])
% %             grid on
% %             grid minor
% %             title(['Slide contours at t = ' num2str((t-1)/fps(f)) sprintf('%s',timestring2)]);
% %             xlabel(['Channel length x' sprintf('%s',distancestring1)])
% %             ylabel(['Channel width' sprintf('%s',distancestring1)])
% %             legend(['Level Increment = ' num2str(diameter(f),'%.4f') sprintf('%s',distancestring2)],'Location','northeast')
% %             saveFileName = [sprintf('%s',cell2mat(datasets(f))) '-contour-' sprintf('%s',ND1) num2str(t-1,'%04d'),'.png'];
% %             export_fig(saveFileName, '-png');
% %             clf;
% %         end

          for i = 1:numel(measurepositions(f,:))...

It then outputs the rest of the complete script alongside some corrupted characters before resuming the normal stream of numbers. The text files scanned before it all had no issues, so it seems to occur at random both in terms of which file it happens in and where in the file it occurs. This is all very bizarre and it overwrites data such that I have no way of reverting the file, and I don't know any way of avoiding the issue. Let me know if you think this is an issue with matlab or whether it may be an issue with something else, such as my hard drive.

[KSSV]

particles = (fscanf(fid,'%f',[9 num]))';

This line write the data into your file....

[Stephen23]

@Matt Kesseler: what OS and MATLAB version are you using?

[Matt Kesseler]

I'm using ubuntu 14.04 LTS and MATLAB version 8.5.0.197613 (R2015a). As I said before, I have used this script many times before without this occuring. I have also discovered the dlmread function which may be more suitable for this process, so I'm going to switch to this and see if I encounter the same problem.

[Jan]

@KSSV: Does this write to the file? It is the command for reading.

[Guillaume]

Yes, fscanf reads, it does not write. In any case, even if it was an fwrite, the operation would not write anything (it would error) since the file has been opened with 'r', read-only permission. I will assume that mathworks has implemented their fopen function properly, in which case the OS itself will ensure that the file is open for reading only.

Most likely, there is a bug in a another section of code that does write to files. Possibly, the wrong path is giving to that writing code.

Answer 1

[Jan]

I think that the problem occurs somewhere else, but not in the shown code.

Why do you open the file in text mode? [EDITED: The following is wrong] Under Windows this could cause strange problems, e.g. when a ^Z is interpreted as EndOfFile or if a \b is interpreted as backspace, such that the number of imported characters can differ from the number of bytes of the file. But under Linux I assume that these interpretations do not happen and that this cannot be the problem. Nevertheless, I avoid the text mode for file access.

Did you close the file after reading? The posted code does not contain a fclose.

[Matt Kesseler]

There was an fclose later in the script. I have run this script on both Linux and Windows without this problem occuring in the past.

[Guillaume]

@Jan,

According to the doc, the only thing that text mode does is replace \r\n by \n on reading (and the opposite on writing), on Windows only. It shouldn't interfere with any other control character.

In my opinion, using text mode for text file should be the advice since it makes the code more portable by uniformising the line endings to \n regardless of the platform.

[Jan]

Using \n works on all platforms reliable. Only Windows' Notepad requires \r\n. All other editors I know handle \n perfectly: Matlab's editor, Notepad++, Wordpad, Word, Emacs, vi, Alpha (for MacOS 7!), BBEdit, UltraEdit, WinEdt - I think this list can be expanded much longer. Then the text mode would be a support for Notepad?

After reading the documentation again and an hour of testing ASCII 8 (backspace \b) and 26 (^Z, End of File), 7 (beep, \a), fprintf, fwrite and fscanf, I confirm, that Matlab's behavior has changed since R5.3, when I tested this the last time. In R6.0 the Linux version failed for M files with \r\n, but in R6.5 this was no problem anymore, and even the Windows version used \n only.

Thanks Guillaume for refreshing my opinion about the text mode handling in Matlab. :-)

[Walter Roberson]

If I recall, historically 't' mode stopped reading at ^Z . I have not tested that for some time.

[Matt Kesseler]

I can also confirm that this error occured with the dlmread command in its place. This time it resulted in inserting random code from another program that I was using, resulting in mostly corrupted characters. So it seems to me like this may be a problem to do with my computer rather than matlab itself.

[Jan]

Again it was a function for reading dlmread which modified a file?! This is extremely strange.

[Matt Kesseler]

Correct! This makes me think it's an issue with the hard drive or computer itself.