From: Jesse Hopkins on
All -

I've noticed that if I open a file for reading using fopen in matlab, the file is locked from other process, which is a good thing.. however, it is still possible to fopen the file from within matlab with 'w', effectively deleting the file.

Is there a way to protect a file from being overwritten while it still has an open file-handle, or to tell if a file is open?
I've got a bandaid function now:
<pre>
function x = isopen(filename)
x = false;
all_fids = fopen('all');

for fid = all_fids
open_filename = fopen(fid);
if strcmp(open_filename,filename)
x = true;
break;
end
end
</pre>

However this code is not very robust, as this will fail if the file in question was opened with a relative pathname, but the check is performed with an absolute filename, or if the file was opened with a relative pathname and the directory has changed since then, etc...
From: us on
"Jesse Hopkins" <na(a)na.com> wrote in message <i2ngd8$cmk$1(a)fred.mathworks.com>...
> All -
>
> I've noticed that if I open a file for reading using fopen in matlab, the file is locked from other process, which is a good thing.. however, it is still possible to fopen the file from within matlab with 'w', effectively deleting the file.
>
> Is there a way to protect a file from being overwritten while it still has an open file-handle, or to tell if a file is open?
> I've got a bandaid function now:
> <pre>
> function x = isopen(filename)
> x = false;
> all_fids = fopen('all');
>
> for fid = all_fids
> open_filename = fopen(fid);
> if strcmp(open_filename,filename)
> x = true;
> break;
> end
> end
> </pre>
>
> However this code is not very robust, as this will fail if the file in question was opened with a relative pathname, but the check is performed with an absolute filename, or if the file was opened with a relative pathname and the directory has changed since then, etc...

one of the potential solutions

if strcmp(which(open_filename),which(filename))

us
From: Jan Simon on
Dear Jesse,

> I've noticed that if I open a file for reading using fopen in matlab, the file is locked from other process, which is a good thing.. however, it is still possible to fopen the file from within matlab with 'w', effectively deleting the file.
> ...
> However this code is not very robust, as this will fail if the file in question was opened with a relative pathname, but the check is performed with an absolute filename, or if the file was opened with a relative pathname and the directory has changed since then, etc...

For this reason and to support thread-save file access I use full path names ever.
You can open a file for writing/deleting from other Matlab sessions also.

In Matlab 6.5 the behaviour was even more strang:
file = fullfile(tempdir, 'TestFile');
f = fopen(file, 'w'); fclose(f); % Create a file
f1 = fopen(file, 'r');
f2 = fopen(file, 'w');
[Name, Permission] = fopen(f1)
>> Permission = 'w'
The file handle f1 got write permissions! But lukily this has been fixed later.

Anyhow, your check function is not robust. A dedicated function for opening files would be better:
function FID = SafeOpen(Command, Name, Perm, Format)
persistent OpenFiles
Name = GetFullPath(Name); % See FEX
if strcmpi(Command, 'open')
if any(strcmpi(Name, OpenFiles))
FID = -1; % And a warning or error
return;
end
FID = fopen(Name, Perm, Format);
if FID < 0; error(['Cannot open file: ', Name]); end
OpenFile = cat(1, OpenFiles, {Name});
return;
else % Command is 'close'
OpenFiles(strcmpi(OpenFile, Name)) = [];
end

Then add check of inputs, let Perm and Format be optional considering the current OS, add MLOCK to catch the "clear all" gags --- and you are still caught by files opened through a drive letter, which was assigned to a mounted path or by different UNC paths.

So I gave up. It is even hard to try a wanted explicite locked file, see:
http://www.mathworks.com/matlabcentral/newsreader/view_thread/287163
http://www.mathworks.com/matlabcentral/newsreader/view_thread/279510

Good luck, Jan