search

GideonZ / 1541ultimate

Official GIT archive of 1541 ultimate II sources
GNU General Public License v3.0
178 stars 45 forks source link

Copy & paste using the Commodore-key +C +V might have a bug? #145

Open Jumpman64 opened 4 years ago

Jumpman64 commented 4 years ago

Description: I copied a PRG file from inside a D64 image into another D64 image within the Ultimate menu (overlay mode) using the copy&paste keys. (The images were in different subdirectories.) This messed up the file allocation in the D64 image, the first few existing PRGs on the disk get corrupted, one of the existing files loads the PRG that was copied by C= + C / C= + V into the image. If you delete the "corrupted" PRG file and copy another PRG to the disk the existing PRGs get even more corrupted with silly loading addresses.

Somehow this isn't easy to reproduce, means it looks like it happens only in a very special case and with a slightly random effect. I tried it with larger game files but that worked. This is what i initially did:

Here are two cases: 01_d64corrupt.D64 "HSG-W.PRG" got overwritten by "VEK1.PRG" which got copied to the image using Ultimate copy&paste.

02_d64corrupt.D64 "DEMO 1.PRG" got overwritten by "VEK1.PRG" which got copied to the image using Ultimate copy&paste. "DEMO 2.PRG" loads "DEMO 1.PRG" and "HSG-VEKTORG..PRG" loads to $0700 instead of $0801.

@GideonZ Any idea if this could possibly be a very rare bug when writing into a D64 image using the copy&paste function?

Otherwise it could only be something with the USB stick? Never had such trouble writing PRGs from the C64 side and i wrote and saved lot of stuff from within the C64. I haven't used the copy&paste within the Ultimate menu so far.

U64 rev1.2. V1.28 - 3.7

d64damage.zip

GideonZ commented 4 years ago

Thank you for this elaborate testing and report. Let's look at it from the bright side: Saving from the C64 goes well; which means that the mechanism for detecting 'dirty' tracks and the re-coding from GCR to binary goes well, and so does the writing to the .d64 file and the USB communication. So basically this whole path can be ruled out - at least for now.

The big difference between writing from the C64 and using the copy/paste function is that the block allocation is not done by the 1541, but by the Ultimate application. If the block allocation goes wrong, this could mean that: 1) the algorithm it is buggy; 2) the data used for the algorithm is out of date.

Assuming 1), we need to rule out 2). So my question: Did you by any chance write to the D64 first from the C64 side, and then proceeded to paste into it? Or vice versa? Especially pasting into the image, while it is mounted on the 1541 will give messy results; as the image in the drive is NOT UPDATED; you'd have to re-mount it.

GideonZ commented 4 years ago

Hey this is interesting.. Considering 02d64corrupt.D64, I can indeed see that VEK1 and DEMO1 and TUNNEL2 seem to start at the same sector (17.13) as the first DEMO 1 and DEMO 2. But then, when I look in the BAM, I can see that none of the sectors that were used for these files are allocated. So I think that allocation algorithm works, but it does not write back the updated BAM. Thus, when you return to the file to copy more into it, it has 'forgotten' that files were written to it before. As it seems, you will probably also corrupt the disk when writing to it from the C64 side, as the 1541 will also think that these sectors are unused. Curious.. :-)

Annotation 2020-06-05 171620

Jumpman64 commented 4 years ago

Assuming 1), we need to rule out 2). So my question: Did you by any chance write to the D64 first from the C64 side, and then proceeded to paste into it? Or vice versa? Especially pasting into the image, while it is mounted on the 1541 will give messy results; as the image in the drive is NOT UPDATED; you'd have to re-mount it.

To mount or not to mount... :) Yes, i thought about that too. First i copied 11 files to the disk using Duplicator 3.0, this was all done on the C64 side. The Ultimate was only used for mounting the disks during disk swaps. After the copying was done the disk was still mounted, all the files were ok and i copied one last file (vek1.prg) to it using the U2 copy&paste keys. I realised that the disk needs to get re-mounted so the content is up to date. Finally the HSG-W.PRG was broken with the VEK1.PRG On the 2nd try to reproduce this the DEMO 1.PRG got affected.

Yes, i agree, if the BAM is screwed, writing files with the C64 to the disk would screw it up more too. ... as we often read in the directories "DON'T VALIDATE" :smile: Ah, after the screw happened i just played around and saved DEMO1.PRG to the disk 02d64corrupt.D64 on the C64. TUNNEL2.PRG was then added with copy&paste, if i remember correctly.

Any senseful test cases you could think of? I copied files to a D64 just using copy&paste, i copied to mounted and unmounted D64, right now did it once again the way i described it, but nothing bad happened - i really hate that! :) (because i think "what the heck did I wrong?!") There's no fast and solid way to reproduce this, at least i haven't found one yet.

So we can rule out the USB stick itself. In case of a stick memory error the whole image should be inaccessible or something, not this in-image BAM corruption... the stick is an old Verbatim 8GB USB2.0 with LED and 15 MB/s write speed. (wrote Tomb Chaser and Santa's Snowball Challenge on it, 100% reliable so far)

quick question: is it possible for you to include an "auto exit overlay menu after mount/run/etc." option like it happens in freezer mode? (sorry for mixing, don't want to open a feature request if it's already on your list :)

GideonZ commented 4 years ago

I was getting bothered also by the overlay menu not exiting after mount/run/etc, so yes, I'll have a look at that.

Coming back to the issue with the corrupted images. This is what I think that happens:

So what is needed, is a mechanism of notifying objects that keep a cache of a (part of) the file, so that when it gets written to, the objects are notified of a change, so the cache can be invalidated. When this is properly implemented, copying files into a D64 will then also appear automatically in the mounted disk and files saved by the C64 will then automatically appear in the browser menu even while it's open. This sounds pretty neat. Doesn't exist at this point... will need some proper design work!

Second thoughts: It may be sufficient to have only one file handle that allows writing. I guess that's how things are in most OS'es anyway. And for good reason, I think, as it will always lead to trouble when things get written to from different sources. For instance: how could I 'invalidate' the BAM-cache that the 1541 drive keeps internally? When I toggle the write protection switch, the 1541 thinks that the disk is removed and reinserted. That might work. :) But it complicates things quite a bit. It may be very acceptable to deny copying into the D64 as long as the file is mounted. I'll think about it, how to grant write privilege to only one 'user'. Don't expect a quick fix within a week. ;-)

smf- commented 4 years ago

You should probably eject the disk from the 1541 before pasting/renaming/deleting and insert it again afterwards & only cache the bam on the u64 during the operation.

Jumpman64 commented 4 years ago

@GideonZ i've found something else:

If copying C64 files with C= + C that contains a dot within the filename, the name gets truncated when pasting it to another image or file system. Example: "name.info" PRG -> "name" PRG

(i've selected several files with spacebar: one "dreher" PRG and "dreher.info" PRG. After pasting them there were two files with the same filename "dreher" on the disk, so you need to use a tool like dirmaster to rename or scratch them. Pasting to the file system delivers a copy error.)