MATLAB Central Newsreader - Severing ties between Matlab and data files when programming

Severing ties between Matlab and data files when programming

Ryan Utz — Wed, 31 Dec 2008 16:16:02 -0500

I'm constantly constructing m-files that batch process or analyze a number of .csv files. When I'm working on one and it messes up for whatever reason (i.e. an error occurs and the process is interrupted), I find that I cannot move, delete, or make changes on the data file that it was last working on. If I try to, Windows tells me that another program (Matlab) is operating on the file (or something to the tune of that), even though Matlab is no longer 'Busy', the error has been posted, and a fresh >> is in the command line.

The only solution I've found to this is to shut down Matlab completely, do what I need to to the data file in question, and restart Matlab to start work again. There has got to be a better way. I'm guessing (and hoping) it's something simple. 'clear' doesn't do the trick.

Anyone have a solution?

Thanks,
Ryan

Re: Severing ties between Matlab and data files when programming

Rune Allnor — Wed, 31 Dec 2008 16:40:03 -0500

On 31 Des, 17:16, "Ryan Utz" <r...@al.umces.edu> wrote:
> I'm constantly constructing m-files that batch process or analyze a numbe=
r of .csv files. When I'm working on one and it messes up for whatever reas=
on (i.e. an error occurs and the process is interrupted), I find that I can=
not move, delete, or make changes on the data file that it was last working=
on. If I try to, Windows tells me that another program (Matlab) is operati=
ng on the file (or something to the tune of that), even though Matlab is no=
longer 'Busy', the error has been posted, and a fresh >> is in the command=
line.
>
> The only solution I've found to this is to shut down Matlab completely, d=
o what I need to to the data file in question, and restart Matlab to start =
work again. There has got to be a better way. I'm guessing (and hoping) it'=
s something simple. 'clear' doesn't do the trick. =A0
>
> Anyone have a solution?

The file stays in OPEN mode after the routine aborts. The solution
is to call FCLOSE on the file handle.

The potential problem is how to get to the file handle. If the file
was opened inside a function, you might not have access to the handle
from the matlab workspace. One solution would be to organize
the code such that you open the file on one function level, and then
call a function with the file handle as argument to do the actual
work.
If the processing function fails, you still have access to the file
handle and can close it:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function data =3DmainFunction(filename)

data=3D[];
fid =3D open(filename);
try
    % loadFile.m does the work associated with the file
    data=3DloadFile(fid);
catch
    % Error during processing are handled here...
end
% ...and this statement is executed in any case
fclose(fid);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Rune

Re: Severing ties between Matlab and data files when programming

David — Wed, 31 Dec 2008 16:40:19 -0500

"Ryan Utz" <rutz@al.umces.edu> wrote in message <gjg5s2$533$1@fred.mathworks.com>...
> I'm constantly constructing m-files that batch process or analyze a number of .csv files. When I'm working on one and it messes up for whatever reason (i.e. an error occurs and the process is interrupted), I find that I cannot move, delete, or make changes on the data file that it was last working on. If I try to, Windows tells me that another program (Matlab) is operating on the file (or something to the tune of that), even though Matlab is no longer 'Busy', the error has been posted, and a fresh >> is in the command line.
>
> The only solution I've found to this is to shut down Matlab completely, do what I need to to the data file in question, and restart Matlab to start work again. There has got to be a better way. I'm guessing (and hoping) it's something simple. 'clear' doesn't do the trick.
>
> Anyone have a solution?
>
> Thanks,
> Ryan

status = fclose('all') closes all open files (except standard input, output, and error), returning 0 if successful and -1 if unsuccessful.

Re: Severing ties between Matlab and data files when programming

ImageAnalyst — Wed, 31 Dec 2008 16:41:45 -0500

On Dec 31, 11:16=A0am, "Ryan Utz" <r...@al.umces.edu> wrote:
> I'm constantly constructing m-files that batch process or analyze a numbe=
r of .csv files. When I'm working on one and it messes up for whatever reas=
on (i.e. an error occurs and the process is interrupted), I find that I can=
not move, delete, or make changes on the data file that it was last working=
on. If I try to, Windows tells me that another program (Matlab) is operati=
ng on the file (or something to the tune of that), even though Matlab is no=
longer 'Busy', the error has been posted, and a fresh >> is in the command=
line.
>
> The only solution I've found to this is to shut down Matlab completely, d=
o what I need to to the data file in question, and restart Matlab to start =
work again. There has got to be a better way. I'm guessing (and hoping) it'=
s something simple. 'clear' doesn't do the trick. =A0
>
> Anyone have a solution?
>
> Thanks,
> Ryan

-------------------------------------------------------------------------
Ryan:
It's not a MATLAB solution but a more general one. Just install
Unlocker.
http://www.download.com/Unlocker/3000-2248_4-10493998.html
Here's the description:
"Ever had such an annoying message given by Windows: Cannot delete
file: Access is denied. There has been a sharing violation. The source
or destination file may be in use or the file is in use by another
program or user. Make sure the disk is not full or write-protected and
that the file is not currently in use. Unlocker is the solution.
Unlocker is an Explorer extension that allows you with a simple right-
click of the mouse on a file or folder to get rid of error message
such as error deleting file or folder, cannot delete folder: it is
used by another person or program."

Unlocker can pry the fingers off the file of whatever application had
gotten ahold of it. Then you can delete the file, or reuse it, or
whatever. It sits in the Windows system tray and pops to life
whenever your attempt to do something with a file is denied because
some program has it locked. It will bring up a window asking if you
want to unlock the file, delete it, and I think some more options.
Regards,
ImageAnalyst

Re: Severing ties between Matlab and data files when programming

Jiro Doke — Wed, 31 Dec 2008 16:52:02 -0500

Rune Allnor <allnor@tele.ntnu.no> wrote in message <36aa9a03-e3ee-4f42-82c3-67b4c138552f@k1g2000prb.googlegroups.com>...
> On 31 Des, 17:16, "Ryan Utz" <r...@al.umces.edu> wrote:
> > I'm constantly constructing m-files that batch process or analyze a numbe=
> r of .csv files. When I'm working on one and it messes up for whatever reas=
> on (i.e. an error occurs and the process is interrupted), I find that I can=
> not move, delete, or make changes on the data file that it was last working=
> on. If I try to, Windows tells me that another program (Matlab) is operati=
> ng on the file (or something to the tune of that), even though Matlab is no=
> longer 'Busy', the error has been posted, and a fresh >> is in the command=
> line.
> >
> > The only solution I've found to this is to shut down Matlab completely, d=
> o what I need to to the data file in question, and restart Matlab to start =
> work again. There has got to be a better way. I'm guessing (and hoping) it'=
> s something simple. 'clear' doesn't do the trick. =A0
> >
> > Anyone have a solution?
>
> The file stays in OPEN mode after the routine aborts. The solution
> is to call FCLOSE on the file handle.
>
> The potential problem is how to get to the file handle. If the file
> was opened inside a function, you might not have access to the handle
> from the matlab workspace. One solution would be to organize
> the code such that you open the file on one function level, and then
> call a function with the file handle as argument to do the actual
> work.
> If the processing function fails, you still have access to the file
> handle and can close it:
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> function data =3DmainFunction(filename)
>
> data=3D[];
> fid =3D open(filename);
> try
> % loadFile.m does the work associated with the file
> data=3DloadFile(fid);
> catch
> % Error during processing are handled here...
> end
> % ...and this statement is executed in any case
> fclose(fid);
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> Rune

If for some reason, you don't have access to the file ID (fid), then you can either do

fclose('all')

to close all open files. Or if you have multiple files and want to close particular files,

fid = fopen('all')

to get all of the IDs of the files that are currently open. Then do

fopen(fid)

to find the file that you want to close and then issue fclose on that ID.

Hope this helps.

jiro

Re: Severing ties between Matlab and data files when programming

James Tursa — Wed, 31 Dec 2008 17:01:02 -0500

Rune Allnor <allnor@tele.ntnu.no> wrote in message <36aa9a03-e3ee-4f42-82c3-67b4c138552f@k1g2000prb.googlegroups.com>...
> On 31 Des, 17:16, "Ryan Utz" <r...@al.umces.edu> wrote:
>
> The file stays in OPEN mode after the routine aborts. The solution
> is to call FCLOSE on the file handle.
>
> The potential problem is how to get to the file handle. If the file
> was opened inside a function, you might not have access to the handle
> from the matlab workspace.

As you mention, try-catch seems like a good way to go, but FYI file handles in MATLAB are simply doubles with integer values, not pointers like in C or C++. So even if the file was opened in a function and you don't have access to the handle directly, one could just guess the handle value. MATLAB seems to start with low numbers (e.g., 3) when opening files, so you could try

fclose(1)
fclose(2)
fclose(3)
fclose(4)
:
etc.

manually at the prompt until you got the file closed. Clumsy, but it should work.

James Tursa

Re: Severing ties between Matlab and data files when programming

Jiro Doke — Wed, 31 Dec 2008 17:25:03 -0500

"James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in message <gjg8ge$e8d$1@fred.mathworks.com>...
> Rune Allnor <allnor@tele.ntnu.no> wrote in message <36aa9a03-e3ee-4f42-82c3-67b4c138552f@k1g2000prb.googlegroups.com>...
> > On 31 Des, 17:16, "Ryan Utz" <r...@al.umces.edu> wrote:
> >
> > The file stays in OPEN mode after the routine aborts. The solution
> > is to call FCLOSE on the file handle.
> >
> > The potential problem is how to get to the file handle. If the file
> > was opened inside a function, you might not have access to the handle
> > from the matlab workspace.
>
> As you mention, try-catch seems like a good way to go, but FYI file handles in MATLAB are simply doubles with integer values, not pointers like in C or C++. So even if the file was opened in a function and you don't have access to the handle directly, one could just guess the handle value. MATLAB seems to start with low numbers (e.g., 3) when opening files, so you could try
>
> fclose(1)
> fclose(2)
> fclose(3)
> fclose(4)
> :
> etc.
>
> manually at the prompt until you got the file closed. Clumsy, but it should work.
>
> James Tursa

The function "fopen" will give you the file ID of files that are open.

fid = fopen('all');

Then you can loop through each of the elements of fid to see if it's the file of your interest:

for idx = 1:length(fid)
  if strcmp(fileIWantToClose, fopen(fid(idx)))
    fclose(fid(idx));
    break;
  end
end