Weird and worrying

This is using my ARMX6 system and its CDROM drive and front-panel
SD card slot.

I’ve been making transfer copies from old CDROMs, etc, onto an SD card.
I’ve just started getting odd behaviour which can be seen by looking at

http://jcgl.orpheusweb.co.uk/temp/compare.jpeg

I’m drag-and-drop copying from a CDROM (left) to the SD card (right). Note
the weird datestamps. The SD card is adfs/sdfs formatted.

Before this happened, I was transferring lots of items per dnd and the
process stiffed the machine at one point. I had to remove the disc and card
and do a power off-on cycle. I then deleted all the most recently copied
items and used discknight to check the sd card. This showed no problem. So
I resumed. Then noticed odd directory datestamps were appearing.

Subdirectories seem to have correct dates. And random checks so far show
that files are loadable and don’t seem corrupted. But of course I may have
missed finding ones that are corrupted!

If I recopy over the existing ‘wrongly stamped’ directory this usually
corrects the datestamp. (I’m using ‘newer’ to avoid needing to recopy the
actual contents.) But the problem now tends to show up when I add new
directiories of material.

I have tried copying from CDROM to ramdisc. And then from ramdisc to
SD card. This seems to make the problem occur less often. But it still
happens. Until yesterday I’d never seen this problem at all, though.
FWIW the datestamps of items do matter particulary as this is a
resource I run a program to scan though, finding files to list in date
order. Helps me track down documents for a ‘biography’ I’m writing.
So having any file dates corrupted would be a real PITA even if
the contents are OK. However as yet only the top level directory of
dnd-ing a directory seems to have its datestamp altered. The contents
have – so far – always seemed OK

Anyone seen this before or can diagnose? I’m worried that the card may
become corrupted and I’ll have to re-copy a load of CDROM files again which
would be a PITA. I’m trying to put the material onto SD cards for
convenience and to save them from any damage/degrading of the old CDRs,
etc.

Jim

It’s extremely worrying. Looking at those directory timestamps as the load/exec addresses they actually are:

The majority of those could be valid load addresses of text files (the ones that start with six FFs), but the two that start with 0s could be lengths.

In other words, this looks like random directory information, which could be due to uninitialised memory, a bug, failed write, failed read… The fact that the object types (dir/file), names and attributes are correct, makes me suspect a bug I’m afraid – it is plausible that something might not be maintaining load and exec addresses for directories correctly under some circumstances.

There may be some other explanation for why those metadata fields are corrupted (in that way) whilst others are not, but the fact that the file is ok makes me suspicious of the code, slightly.

As yet I’ve only seen this with the ‘top level’ directory I’ve dnd copied. And a repeat generally sorts it first time. However someone on the email list for R-Comp systems has reported seeing files with ‘future’ datestamps. That is more alarming.

I had wondered if the SD card was faulty. But the report from someone else implies this may be a more general problem. :-/

All I’m doing is a dnd of directories of item, from the CDROM’s filer window to the SD card’s filer window.

BTW discknight tells me ‘disc is good’ and shows no sign of finding a problem when I do the basic check.

It’s inconvenient, but try using *Copy with the appropriate runes for a while and see if it can be reproduced.

That would localise the problem either to the FS or to FilerAction.

Whilst diagnosing the Disc Error 20/23 issue on an Iyonix, I noticed that the Wimp’s refresh of the window files were being copied into, was increasing the amount of failed writes I was seeing.

I’ve also seen a very similar same issue with a USB stick on a Pi, which turned out to be data being written to the card faster than it could handle, I switched to a different media in the end.

I’d be inclined to do a CRC check on the files, if the directory entries are wrong there’s a real possibility file contents are also wrong.

So far I’ve only seen the ‘top directory’ datestamp being messed up. I’ve not yet seen any file that was corrupted. So the directory entries / contents seem OK, including the timestamps of subdirectories. But of course this may be a needle in a haystack, and I’ve not yet been stabbed by a needle!

I’ve been using !Locate to scan for any items that report ‘future’ timestamps. Not found any apart from the above ‘top level directory’ examples.

What is the date of the OS version you have on the ARMX6? And were the cards you were writing to FileCore formatted or FAT32?

In the run-up to the Wakefield Show we were investigating a problem that a customer was having with some SD cards we had supplied. He could not read them reliably on his ARMX6, so he sent them back. We tried on ours and the cards were fine — we used DirSync set up so that it read and compared every byte of each file, and the cards were perfect.

At that point we were on a version of the OS from June 2016. We upgraded to RComp’s version 11 release for the ARMX6, which has a date of 18 February 2018. We then found that with the front panel SD card reader we could no longer read the SD cards. Nor could we write reliably to FileCore format cards. We did quite a few more tests, using an external SD card reader, and using FAT32 format cards. I’ll dig those tests out and post them here.

We reported the problems to RComp and Andrew sent us another test ROM which I think was a pure ROOL ROM without some extras that RComp add for the ARMX6. That ROM had the same problems. I do not know why this only affected the front panel SD card reader.

It was just before the show so neither we not Andrew (I guess) had much time for more investigation. We reverted to the June 2016 OS we were using before.

If there are problems writing files to SD cards, there could easily be problems writing directory data.

I have recently noticed some problems with an ARMX6 and the internal card reader. I use CF cards in my Canon, and have never had any cause for concern. Earlier this week I transferred some images from the CF card to the SSD in the ARMX6 with no problem. However, on attempting to delete the images from the card the ARMX6 completely froze, needing a power cycle to restart. On checking the card it looked corrupted – filenames had extraneous characters etc and any attempt to delete the images resulted in another lockup and power cycle (several times), although the images were still readable.

I also have an external card reader. Using this to access the card allowed normal behaviour (the filenames were still ‘broken’. However, the card could be read/written as normal in the external reader, and was fine when replaced in the camera.

I have had occasional odd behaviour with the internal reader before with earlier OS versions. I am currently on v. 5.25 (25 April 2018).

Summary of my testing, a few weeks ago, if the ARMX6 internal card reader:

External card reader: seems to behave in all circumstances (FAT/FileCore, OS release 8 or 11)

Internal card reader:

OS release 8 (29 June 2016)

• Often has problems writing to FAT32 format SD cards
• Can’t remember whether reading FAT32 is reliable
• Reading or writing FileCore cards generally reliable

OS release 11 (18 Feb 2018)

• Very unreliable reading or writing FileCore format SD card
• Reading FAT32 card was reliable
• Writing FAT32 card not tested

The OS release 10 (January) was not tested exhaustively but it had the same problems as OS release 11 reading the FileCore format card.