http://qs1969.pair.com?node_id=11131356


in reply to Re: DateTime throwing an error
in thread DateTime throwing an error

Hi Alex,

Thanks for the reply. Your right, something had to have changed. But it wasn't the script. After I made the post I looked at the errors more carefully; in particular the error with the most information.

Unrecognized character \x0E; marked by <-- HERE after warnings;<-- HERE near column 14 at /usr/local/share/perl/5.28.1/Role/Tiny/With.pm line 4.

I opened file at the end of that path "With.pm". Then I looked at line 4. Sure enough there was some odd control character there. In fact there were odd control characters peppered through the file. But the strange this is the timestamp on the file was from 2019. So it was the original timestamp of the installed file (my script was made in 2021). Fortunately, I have a copy of this same file (With.pm) on another Linux box I have that was built at the same time. I checked that file and it had no control characters. I swapped it out with the (corrupted) one. Then ran my script - and it was fine. No more errors.

My problem is solved but what I don't understand is how the file got corrupt (maybe a power surge or power outage?). But what I really don't understand is how that file from 2019 (With.pm) was changed but the filetimestamp didn't change. Maybe a corruption doesn't always trigger a timestamp update?

Thanks again for the reply. I was going to write that I had it solved just as I saw your post.

Mike

Replies are listed 'Best First'.
Re^3: DateTime throwing an error
by afoken (Chancellor) on Apr 16, 2021 at 10:28 UTC
    what I don't understand is how the file got corrupt

    Time for a filesystem check (fsck) and a check of the disks (smartctl). If a RAID is involved, also check the RAID for errors (cat /proc/mdstat for a Linux SW RAID).

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
      Yeah, will do.

      I should have mentioned: this is part of a security application I wrote to run on a series of Raspberry Pi's. They each take a picture in a certain area and move it over to the main Pi which processes the images into a DB and finally into a simple web page which this Pi hosts.

      The "hard drive" of this Pi is actually a micro SD card. So no Raid or anything fancy.

        The "hard drive" of this Pi is actually a micro SD card.

        Any flash memory of course has a limited number of write cycles, and since a Linux system is constantly writing log files etc. to the disk, and you say you're regularly writing image files to the disk, two years isn't an unreasonable time for the SD card to start failing if the system was in operation the whole time. I'm also not sure how widespread Wear leveling currently is on SD cards.

        But what I really don't understand is how that file from 2019 (With.pm) was changed but the filetimestamp didn't change. Maybe a corruption doesn't always trigger a timestamp update?

        Physical damage to the storage medium (or corruption of the flash cells) wouldn't be reflected in the file's timestamp. However, I can almost guarantee you that this wasn't the only file affected. I'd strongly recommend replacing the SD card ASAP. Recently there are also new "endurance" SD cards (e.g. from SanDisk, Samsung, and Transcend) that promise to have higher write endurances.

Re^3: DateTime throwing an error
by perlfan (Vicar) on Apr 16, 2021 at 04:18 UTC
    > I don't understand is how the file got corrupt (maybe a power surge or power outage?)

    Sounds like it was purposefully edited somehow. Or some well aimed sun spots. Let's go with that :)