| Re: Solved: Re: [hatari-users] ICD hard drive image |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-users Archives
]
Hi,
On 5/20/19 11:40 PM, Charles Curley wrote:
On Mon, 20 May 2019 21:57:31 +0300
Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
I had set the image to read only. Allowing writes to it let the
desktop import several of the partitions. So read-only images are
not allowed. Bug? Or if that's a feature, please document it.
Could you test attached patch that changes this?
I applied the patch ("git apply ro-asci-support.patch") and compiled.
I ran it with the write permission removed, and got no debug message.
DEBUG: Sound: Disabled
INFO : Mounting hard drive image '/home/charles/projects/hatari/fast.forth.img'
INFO : Mounting hard drive image '/home/charles/projects/hatari/drived.img'
INFO : Mounting hard drive image '/home/charles/projects/hatari/atari.micropolis.img'
DEBUG: Checking GEMDOS O: HDD: /home/charles/projects/hatari/cdrive
INFO : GEMDOS HDD emulation, O: <-> /home/charles/projects/hatari/cdrive.
DEBUG: memory_map_Standard_RAM total=2097152 ram0=2097152 ram1=0 mmu0=131072 mmu1=131072
With that, I tried creating a directory in the test image. That
produced seven instances of "ERROR: Could not write all bytes to hard
disk image."
Ok, so it works as well as read-only HD can. Thanks!
I then inverted the logic of the return from File_Lock. That was *not*
what I wanted.
If you want just a warning about the read-only status of HD,
attached patch adds that too. Hopefully the message also makes
the logic clearer.
Maybe some of these messages should go to GUI dialog, so that user
notices them better?
- Eero
DEBUG: Sound: Disabled
INFO : Mounting hard drive image '/home/charles/projects/hatari/fast.forth.img'
ERROR: Cannot lock HD file for writing!
INFO : Mounting hard drive image '/home/charles/projects/hatari/drived.img'
ERROR: Cannot lock HD file for writing!
INFO : Mounting hard drive image '/home/charles/projects/hatari/atari.micropolis.img'
DEBUG: Checking GEMDOS O: HDD: /home/charles/projects/hatari/cdrive
INFO : GEMDOS HDD emulation, O: <-> /home/charles/projects/hatari/cdrive.
DEBUG: memory_map_Standard_RAM total=2097152 ram0=2097152 ram1=0 mmu0=131072 mmu1=131072
So I went back to your patch, and inserted a new message right after
the first fopen. That showed up properly. See the attached patch file,
which replaces yours. It's a diff against master,
7f47e042ae7dd5f9d3681c631bb65cbcce2c4b8d.
DEBUG: Sound: Disabled
INFO : Mounting hard drive image '/home/charles/projects/hatari/fast.forth.img'
INFO : Mounting hard drive image '/home/charles/projects/hatari/drived.img'
INFO : Mounting hard drive image '/home/charles/projects/hatari/atari.micropolis.img'
ERROR: Cannot lock HD file for writing!
DEBUG: Checking GEMDOS O: HDD: /home/charles/projects/hatari/cdrive
INFO : GEMDOS HDD emulation, O: <-> /home/charles/projects/hatari/cdrive.
DEBUG: memory_map_Standard_RAM total=2097152 ram0=2097152 ram1=0 mmu0=131072 mmu1=131072
Apparently File_Lock doesn't detect read-only files, at least not on
Linux. I'm no expert on BSD-style file locking, and don't even know if
Linux supports it.
So here's what I see: I have two other disk images, one partition
each. They show up as C: and D:. Then four partitions from the new
image, E: through H:. I: is my GEMDOS mounted directory. J: to O:
are further partitions from the new image. Is that the drive
ordering you want, or should the GEMDOS drive show up as O:? I was
expecting it at O:.
Hatari default for GEMDOS HD partition ID is "skip", i.e. place it
after partitions that Hatari HD code recognizes.
In any of the cases where on-disk HD driver and Hatari interpretation
of the partition tables mismatches, GEMDOS HD won't be the last one.
This mismatch can happen easily because Hatari doesn't know which
HD driver is on the HD image or what partition types that recognizes
/ supports (partition support *does* differ between different
drivers).
As a result, GEMDOS HD can mask one of the real HD partitions (or
more, if there are multiple GEMDOS HD partitions specified).
That's why there's an option to explicitly set the GEMDOS HD partition
ID:
--gemdos-drive X
Nice. Exactly what I needed. Thank you.
diff --git a/src/hdc.c b/src/hdc.c
index 838a4f3b..86b4007c 100644
--- a/src/hdc.c
+++ b/src/hdc.c
@@ -828,13 +828,16 @@ int HDC_InitDevice(SCSI_DEV *dev, char *filename, unsigned long blockSize)
if (filesize < 0)
return filesize;
- fp = fopen(filename, "rb+");
- if (fp == NULL)
+ if (!(fp = fopen(filename, "rb+")))
{
- Log_Printf(LOG_ERROR, "Cannot open HD file read/write!\n");
- return -ENOENT;
+ if (!(fp = fopen(filename, "rb")))
+ {
+ Log_Printf(LOG_ERROR, "Cannot open HD file for reading!\n");
+ return -ENOENT;
+ }
+ Log_Printf(LOG_WARN, "HD file is write protected!\n");
}
- if (!File_Lock(fp))
+ else if (!File_Lock(fp))
{
Log_Printf(LOG_ERROR, "Cannot lock HD file for writing!\n");
fclose(fp);