Detecting if a file is open

[gOS]

I'm wondering if there is a better way to do this.

fid = fopen('testfile.txt','w')

if(exist('fid'))
   if(isequal(ferror(fid),''))
     fclose(fid);
   end
end

essenially, I'm assuming that if ferror is an empty string, then the file needs closed. I'm using try catch error handling, and just want to make sure everything is cleaned up properly before I exit the specific function. This is useful when you want to work with a file without having to completely shut down octave and restart it.

Is there a method that is more often used to tell if a file is open? Perhaps more reliably? I just played around until I found this.

[Sergei Steshenko-2]

--- gOS <bkirklin@...> wrote:

>
> I'm wondering if there is a better way to do this.
>
> fid = fopen('testfile.txt','w')
>
> if(exist('fid'))
>    if(isequal(ferror(fid),''))
>      fclose(fid);
>    end
> end
>
> essenially, I'm assuming that if ferror is an empty string, then the file
> needs closed. I'm using try catch error handling, and just want to make sure
> everything is cleaned up properly before I exit the specific function. This
> is useful when you want to work with a file without having to completely
> shut down octave and restart it.
>
> Is there a method that is more often used to tell if a file is open? Perhaps
> more reliably? I just played around until I found this.
> --
> View this message in context:
> http://www.nabble.com/Detecting-if-a-file-is-open-tp17566839p17566839.html
> Sent from the Octave - General mailing list archive at Nabble.com.
>
> _______________________________________________
> Help-octave mailing list
> Help-octave@...
> https://www.cae.wisc.edu/mailman/listinfo/help-octave
>

I do not understand what problem you are trying to deal with - I see at least two
issues:

1) fid <-> file relationship;
2) fid value for open files.

I solve 1) using a trivial naming connection, for example:

my_file = "my_file.txt";
my_file_fid = fopen(my_file, "w");

2) is trivial - open files have positive fids.

You may also organize fids as a hash table ("struct" in 'octave' terms) and delete fid from
the table as soon as file is closed, so the list of keys will represent the list of currently
open files.

Regards,
  Sergei.

Applications From Scratch: http://appsfromscratch.berlios.de/


     
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[gOS]

Let me give you a specific example:

function = foo(bar.txt)

try
   fid = fopen(bar.txt)
   if(fid < 0)
      warning('file never opened)
      return;
   end

   % do a bunch of stuff with the file

   % ! an unforeseen error occurs here %

   % do more stuff with the file

   fclose(fid)

catch

  % detect whether the file is still open (see original post)

  if ( fileIsOpen )
     fclose(fid)
  end
end

%%%%%%%%%%%End Example%%%%%%%%%%%%%%%%%%%%%%

The point is that if you never close fid with fclose, then the file remains opened after the function terminates. I assume that this is normal, expected behavior for Octave, but it is always wise to clean up resources when you are done using them. If you never call fclose, you can't access the file again in Octave, using windows explorer, or any other interface, until you close octave and then restart it.

So quite simply, I'm trying to detect whether octave still maintains control of a file or if it has closed it. If the error occurs after the fclose, there is no point to close it again, especially as this will throw another error.

After calling fopen, fid retains its value regardless of whether the file has been closed or not. So fid is not a reliable indicator as to whether the file is open or not.

Does this make more sense now?

gOS wrote:

I'm wondering if there is a better way to do this.

fid = fopen('testfile.txt','w')

if(exist('fid'))
   if(isequal(ferror(fid),''))
     fclose(fid);
   end
end

essenially, I'm assuming that if ferror is an empty string, then the file needs closed. I'm using try catch error handling, and just want to make sure everything is cleaned up properly before I exit the specific function. This is useful when you want to work with a file without having to completely shut down octave and restart it.

Is there a method that is more often used to tell if a file is open? Perhaps more reliably? I just played around until I found this.

[John W. Eaton]

On  2-Jun-2008, gOS wrote:

| Let me give you a specific example:
|
| function = foo(bar.txt)
|
| try
|    fid = fopen(bar.txt)
|    if(fid < 0)
|       warning('file never opened)
|       return;
|    end
|
|    % do a bunch of stuff with the file
|
|    % ! an unforeseen error occurs here %
|
|    % do more stuff with the file
|
|    fclose(fid)
|
| catch
|
|   % detect whether the file is still open (see original post)
|
|   if ( fileIsOpen )
|      fclose(fid)
|   end
| end

You want unwind_protect, not try/catch.

jwe
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[gOS]

John W. Eaton wrote:

You want unwind_protect, not try/catch.

Except that unwind_protect is not compatible with Matlab, correct? Maintaining 2 separate scripts to do the exact same thing so that I can differentiate between try/catch and unwind_protect is not only unacceptable, its bad coding practice and leads to maintainability issues.

[John W. Eaton]

On  2-Jun-2008, gOS wrote:

| Except that unwind_protect is not compatible with Matlab, correct?
| Maintaining 2 separate scripts to do the exact same thing so that I can
| differentiate between try/catch and unwind_protect is not only unacceptable,
| its bad coding practice and leads to maintainability issues.

Until the very latest Matlab release, Matlab had no way to do the
equivalent of unwind_protect.  Now, they have of course chosen to
implement something that sort of does the same thing, but in a
completely different way.  There has been some discussion of this
feature on the lists already, if you are intersted in helping out.

jwe
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[David Bateman]

John W. Eaton wrote:

> On  2-Jun-2008, gOS wrote:
>
> | Except that unwind_protect is not compatible with Matlab, correct?
> | Maintaining 2 separate scripts to do the exact same thing so that I can
> | differentiate between try/catch and unwind_protect is not only unacceptable,
> | its bad coding practice and leads to maintainability issues.
>
> Until the very latest Matlab release, Matlab had no way to do the
> equivalent of unwind_protect.  Now, they have of course chosen to
> implement something that sort of does the same thing, but in a
> completely different way.  There has been some discussion of this
> feature on the lists already, if you are intersted in helping out.
>  

To do it matlab's way we need the new OOP code of matlab introduced in
2008a in Octave and create and object with a destructor with the
unwind_protect code.. If you really have to have the matlab compatible
way of doing it then something like the thread

http://www.cae.wisc.edu/pipermail/octave-maintainers/2008-March/006503.html

is an approximation of the matlab onCleanup function.

D.


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[John W. Eaton]

On  2-Jun-2008, David Bateman wrote:

| John W. Eaton wrote:
| > On  2-Jun-2008, gOS wrote:
| >
| > | Except that unwind_protect is not compatible with Matlab, correct?
| > | Maintaining 2 separate scripts to do the exact same thing so that I can
| > | differentiate between try/catch and unwind_protect is not only unacceptable,
| > | its bad coding practice and leads to maintainability issues.
| >
| > Until the very latest Matlab release, Matlab had no way to do the
| > equivalent of unwind_protect.  Now, they have of course chosen to
| > implement something that sort of does the same thing, but in a
| > completely different way.  There has been some discussion of this
| > feature on the lists already, if you are intersted in helping out.
| >  
| To do it matlab's way we need the new OOP code of matlab introduced in
| 2008a in Octave and create and object with a destructor with the
| unwind_protect code.. If you really have to have the matlab compatible
| way of doing it then something like the thread
|
| http://www.cae.wisc.edu/pipermail/octave-maintainers/2008-March/006503.html
|
| is an approximation of the matlab onCleanup function.

But also note that if you want "Matlab compatibility" for cleanup
functions, then you are restricting your Matlab users to the latest
2008a release of Matlab...

I think the cleanup function idea (or unwind protect) is the cleanest
way to do what you want, but for the particular case of deciding
whether a file is open, you might try using

  open_fds = fopen ('all');

jwe
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[gOS]

John W. Eaton wrote:

But also note that if you want "Matlab compatibility" for cleanup
functions, then you are restricting your Matlab users to the latest
2008a release of Matlab...

I think the cleanup function idea (or unwind protect) is the cleanest
way to do what you want, but for the particular case of deciding
whether a file is open, you might try using

  open_fds = fopen ('all');

jwe

I'm not quite sure how I missed that option in the documentation, but that should help. Thank you.

Also, 2008a isn't in use here at the moment so pretty much all of that isn't applicable for my case, for now. Thank you for the insight though.