RE: File conflict in Windows

Hi Tom,  

> run my simulation program,
> g4beamline, to generate a .root file, then open it in Root and generate
> some histograms from TNtuples contained in the file.

The MS Windows file system does block any access to the file as soon as it is kept open with "write" access by some program. It blocks the "write"/ "change" access as soon as the file is open with the "read" access somewhere. Windows does provide the special way to open the "shared" file access. However to gain anything from this option *all* programs (including MS File Explorer) those are going to access this file should open this file with the said option.  

> While the file is open in Root, I cannot delete it using Windows explorer.
 

Do you think it is unreasonable?
There are two scenarios

1. Either you can not change (delete, write append ...) the file that had been open by some program or
2. You can, but that program should not try to access the file anymore or crash.

The average Linux file system doesn't provide such level of the protection. I would like to call your attention that this is the feature of the Windows file system rather the concrete Windows application.  

There is the simple and universal solution.  

If your application doesn't need the file access anymore it (*your* application) should close it. That's. This way the file will be available for any kind of operations to the other programs. This is safe, and this should work properly with either file system / OS combinations.  

Hope this helps,
Valeri Fine
BNL, STAR    

From: owner-roottalk_at_pcroot.cern.ch on behalf of Tom Roberts Sent: Sun 2/11/2007 3:38 PM
To: 'ROOT Talk'
Subject: [ROOT] File conflict in Windows

I have having problems with a file conflict in Windows that does not happen in Linux.

I am using Root as a histogramming system, and have written a GUI to make it easier to use by non-experts. I run my simulation program, g4beamline, to generate a .root file, then open it in Root and generate some histograms from TNtuples contained in the file.

The problem comes when I try to iterate this. Once the file is open in Root, g4beamline gets an assert error that the NTuple it tried to create in the file does not exist (null pointer). While the file is open in Root, I cannot delete it using Windows explorer. If I remember to manually close the file in Root before re-running g4beamline, all is well -- g4beamline overwrites the old file with a new one, and Root can then open it and construct new histograms.

In Root the TFile is opened "READ", and in g4beamline the TFile is opened "RECREATE".

Does anyone know of a workaround? Or do my users just have to remember to close the file before re-running g4beamline?

For instance, is there some way to open the TFile with read+write in Root even though I will just be reading it -- will that trick Windows into letting another program write it simultaneously? Or is there some other way of "sharing" the file? In all cases when g4beamline runs it should delete the entire contents of the file and start over creating it.

Tom Roberts Received on Mon Feb 12 2007 - 00:12:46 CET