ISO image file modified by SIMH and then unreadable #1094
Comments
|
This is a severe flaw in SIMH’s disk system that really needs to be addressed. It should not be appending arbitrary data other tools don’t understand to disk images. If it wants to maintain its own metadata, it should do so in a sidecar file. Just treating CD-ROM devices as read-only is grossly insufficient since a disk image can be used by physical hardware and more than one emulator. The overall change to modify disk images outside their boundaries really needs to be reverted, and re-added after being made to use a sidecar file. |
|
On Tue, Dec 28, 2021, 17:42 Chris Hanson ***@***.***> wrote:
This is a severe flaw in SIMH’s disk system that really needs to be
addressed.
I find it very disheartening that the ego of one individual is preventing
this from being appropriately addressed.
|
|
There is another issue open on the same topic. I offer three possible solutions.
Then, those who like the invisible addition of metadata can have that done, by adding an enable to their .ini files; and those who don't won't see it anymore. In general, the addition of incompatible behavior should be under control of a user accessible mode switch, and the default should be prior behavior. |
|
The problem as described was indeed an oversight since CDROM devices were not attached (under the covers with as read only). That problem was fixed on 11/7/2021. A ISO image that had been modified (adding the aforementioned meta-data) can be cleaned with:
Thanks for finding this bug. Note that the behavior which did not force a read-only attach was inherited from the pdp11_rq.c some 12 years ago. The 3.x code still does not force -R for CDROM devices at attach time. |
Right, but even having opened a container in the update mode, since no write ops were coming from the guest OS for a CD-ROM device, the simulator would never have written anything back to the CD-ROM image! So the open mode for the container was actually irrelevant (but surely, opening read-only is a better choice in this case, in general). It was 4.x's behavior to judge if the container was "updateable" and immediately mark it so with a "signature" -- all stems from the fact of #1059. |
As a side note, I personally would have never looked at "ZAP" in help (until it was pointed out to me) while searching for a command to remove the signature, because the meaning of the verb suggests destroying an entire object, rather than stripping just a part of it. IDK why "zap" was a verb of choice for this kind of action. |
|
For crying out loud... doesn't anyone read the source code anymore? Or understand it?
The RRD40 (CDROM) is typed as READ ONLY in the pdp11_rq.c simulator code. Software CANNOT WRITE TO IT. Attaching it read-only is unnecessary and counterproductive. Data files are attached read/write BY DEFAULT so that users can examine and modify them through the simulator interface, if they need to. This is true of read-only devices like paper-tape readers and card readers (and CDROMs) and write-only devices like paper-tape punches and line printers. This behavior has been present since day 0 of SimH. The simulator interface can do lots of things that real hardware can't, like randomly access sequential devices, write to read-only devices, and read from write-only devices. These powerful capabilities are present to facilitate debugging, and I have used them on numerous occasions. What it never did, though, was modify a data file EXCEPT under EXPLICIT user direction. |
… meta data At this time: - The ZAP command exists to remove meta data from containers that have it. Container files processed by the ZAP command will generally be restored to the size it was before the addition of the meta data and the file time stamps will be unchanged. - Newly created containers get meta data. - At attach time, containers that don't have meta data, but have recognized file systems that fit within the drive it is being attached to get meta data added without changing the file timestamps. - Containers that don't have meta data and don't have a recognized file system that is <= the drive size are attached without comment and without adding meta data as long as the drive is NOT set to autosize (controllers that support multiple drive types all default to autosize, which can explicitly be disabled on a drive by drive basis). - Containers that don't have meta data which are > the drive size can only be attached read only. - Containers with meta data can not be attached to a different controller at all if the container size is smaller than the drive on the other controller. - Containers that have meta data can be freely be attached to the controller that they were attached to when they got the meta data. If a file system is detected, it will be reported. Otherwise if no recognized file system is found, the attach will be silent. File system detection reporting can be suppressed with -Q on the attach command. - Containers with meta data can only be attached read only to a different controller if the container is larger than the drive it is being attached to. In the future: - In general, containers with meta data (or recognized file systems) will be attachable to MSCP and SCSI controllers, as long as reasonable sector sizes and file system not requiring interleaving have been found. - Containers without meta data will only be attachable if autosize is disabled and the container is <= the size of the drive. - Explicitly setting a drive type on a unit will implicitly disable autosizing. If a user wants to set the default drive for a unit and still allow autosizing they must explicitly set the unit to autosize after setting the drive type. Relevant to: #1065, #1059, #1094, #1100, #1118, #1117
|
I just ran into a variant of this. I had an ISO image mounted on a simulated RRD42. Then, since metadata had been written to the ISO image marking it as a specifically RRD42 image, I was unable to mount it on a simulated RRD40:
Shouldn't the RRD40 accept RRD42 images, and vice versa? Certainly this would have worked on real hardware. |
Were you using the latest code from the master branch? When had you attached the NetBSD-9.2-vax.iso to a SCSI device set as RRD42, I suspect that you'd done it quite a while back. If, on the original simulator with the RRD42 drive (using current version), you: You can then attach that same ISO to a (current version) Qbus/Unibus simulator without issue. This problem was fixed with 5015d6a More robust/reliable/clean support for ISO 9660 images is coming. |
Any attach of an ISO 9660 file system is done Read Only since that file system is logically non-writable. Related to #1094
CDROM ISO image file modified by SIMH and then unreadable
An ISO CD image file (install of VMS 5.5-2H1) worked fine in previous VAXStation SimH, but was apparently modified by a previous SIMH run , and now gives error in current SimH - "... incompatible with the RZ device". Reverting to a copy of the ISO from before 2020 and adding -R to the Attach command, all works fine. However SimH should Not make changes to CDROM image files, much less thereby making them unreadable!
the output of "sim> SHOW VERSION" while running the simulator which is having the issue
VAXstation 3100 M38 (KA42-B) simulator V4.0-0 Current simh git commit id: 6d9a55d
how you built the simulator or that you're using prebuilt binaries
Built using make all from current SIMH_Master on Raspberry Pi. Same effect when using build done on Windows 10 Intel.
the simulator configuration file (or commands) which were used when the problem occurred.
set rz4 cdrom
attach -R rz4 VMS552H4.iso
the expected behavior and the actual behavior
"RRD40 container created by the VAXstation 3100 M38 (KA42-B) simulator is incompatible with the RZ device on the VAXstation 3100 M38 (KA42-B) simulator"
you may also need to provide specific pointers to data files that may be necessary to demonstrate the problem
sim> sh rz
RZ 7 units
RZ0 426MB, attached to lamps1_disk0.img, write enabled
RZ25, autosize, RAW format
RZ4 593MB, not attached, write locked
RRD40, autosize, AUTO detect format
RZ5 593MB, attached to empty.tape, write enabled
TZ30, autosize, SIMH format
sim> diskinfo VMS552H4.iso
Container: /home/pi/VMS/LSL/LAMPS1/VMS552H4.iso
Simulator: VAXstation 3100 M38 (KA42-B)
DriveType: RRD40
SectorSize: 512
SectorCount: 401384
TransferElementSize: 1
AccessFormat: RAW
CreationTime: Mon Jul 27 16:35:39 2020
Container Size: 205,508,608 bytes
sim>
The text was updated successfully, but these errors were encountered: