Its a 1.5 GB file with a ton of directories and objects in it.
hdfview OOM’d. That is bad. Worse, it corrupted the file.
When a file is given on the command-line, I think it should default to opening that file read-only. In addition, if data corruption is a potential issue with hdfview, then I would recommend that ‘open’ in the GUI means read-only and a separate open-for-write be provided.
I think the default open for writing is too risk, particularly given this experience.
Maybe the headline of this thread should be changed to all HDF5 tools should default to read-only open. I just tried using h5ls on a file that I was already looking at in hdfview and h5ls failed with error “unable to open file”. I suspect this is because the file may already have been corrupted by hdfview. But, I was using hdfview and h5ls from 1.10.2 install.
And, it just seems prudent that all HDF5 tools should open files read-only and users should have to take action (with cl args or something) if they want read-write.
The h5ls (or h5dump) utility does not appear to modify an HDF5 file.
The beta version of HDFView 3.0 did modify an HDF5 by default. As of the released version of HDFView 3.0 (that uses HDF5-1.10.3) we changed the behavior so that an HDF5 file is not modified by default, and you can change the default way files are opened by selecting User Options from the Tools menu at the top of the HDFView window. (HOWEVER, if you had the HDFView 3.0 beta installed previously, the default will be read-write, because the HDFView 3.0 options file (.hdfviewx) is already there (unless you delete it first).
If you are on Windows, you will get an “unable to open file” error if you have a file opened in HDFView, and you try running h5ls on the file. Windows only allows one file to be open at a time. The timestamp will also appear to be modified, but when HDFView closes the file, the timestamp on the file will revert back to the original timestamp.
On Unix, you should be able to open the file in HDFView and use h5ls at the same time.
Ok, well, the problem with h5ls opening the file then must have been that hdfview had already corrupted it. Which is strange because hdfview seemed to continue to work on the file just fine
The mode of operation you describe for these tools is, IMHO, the preferred one.
I believe HDFView 3.1.0 is opening the hdf5 file in Write mode(by default)… It has the settings called default File access mode. But i believe it didn’t work.
The latest HDFView will use the value last set in User Options in the users property file.
If there is an existing property file is will that value, if there is no property file it will default to RO.
i have set the value as Read only in the User options(under Tools menu).
By default if am I opening the hdf file via the file menu, it opens a read only.
If I double clik file for opening, it always opens as Write mode.
Can you please let me know more about the property file.
The settings in the User Options should be saved in a property file in the root user folder; by default “.hdfview-3.1”
The double click of a file from the file system which then opens up the file with HDFView should use the setting in the property file. It is a bug otherwise.
It is possible on windows to have a file open by multiple processes at the same time.
Just launch h5ls with a redirection of its ouput into a log file, open this log file in a text editor such visual code during h5ls work. The log file is open by both h5ls and visual code, and it works.
Could be interesting to investigate how visual code is able to read a file during its generation by another process.
As jpsinfotech write in 2019, and I confirm now with HDFView 3.1.0 as well as 3.1.2:
The Tools -> User options -> Default File Access Mode has the desired effect on the configuration file (C:\Users\USERNAME\.hdfview3.1.2) and for when you use the File -> Open menu entry to open a file.
But if you open a file via the command line (hdfview.bat some_file.h5) or by having a filename extension associated to launch such a command when a file is double-clicked in the Windows Explorer, then the setting is ignored and the file is opened in writable mode.
To check which mode was used, I navigate to any dataset in my file, double-click it to get the table-window and then double-click a cell. When read-only mode the cell just gets selected, while in writable mode the cell becomes a text editor and I can type another value (e.g. for uint32) or text (for a string). When closing the table-window a dialog-box asks me whether to save or cancel.
Thus I am pretty sure that there is still a bug somewhere. Perhaps when launched with a filename on the command line the opening starts before the configuration has been loaded or applied? Or perhaps the command-line opening uses a different function than the File -> Open menu action?
Although fixing the default behavior would be enough for me, it could potentially be useful to add a command-line argument to override the default, e.g. -file.mode=r or -file.mode=rw.
To describe my motivations for wanting to be sure files are opened read-only:
We store scientific raw-data from multiple users on a network storage, read-only for most users but some have elevated permission with the intent of being able to reorganize files in directories etc., but we don’t want to make it easy to edit contents or corrupt files by having multiple users open them as writable at the same time.
It is also ugly that the filesystem timestamps for files are no longer showing when they were acquired, but the last time that someone just double-clicked the file to read out something with HDFView (which happens with the read-write mode even if the user makes no change in any dataset).
I just checked on my Linux box and can confirm the general behavior described above. When opening an HDF5 file with HDFView 3.1.2 directly form the command line hdfview.sh file.h5 the file is opened read-write. When HDFView is launched first and the file is opened from the menus, it is by default opened read-only.
Standard setting from Tools->User options is to open ad read-only.
Since I never use HDFView for any other purpose than inspecting the contents of a file, I would ideally have it read-only.
Yes I believe we have fixed this in the next release. Unfortunately, we are having issues with creating HDFView on a mac at the moment, which is the final holdup.
