save.dat file checker

[Ed_P]

What's the command Porteus uses when booting to check the condition of the savedat file? Is it fsck and if so with what options?

[babam]

fsck cheatcode.

finit (initrd)

Code: Select all

# Error checking a save file.
fsck_dat() { echo $i"checking $1 for errors"
fs=`blkid $1 | egrep -o ' TYPE=[^ ]+' | cut -b8-10`
if [ $fs = xfs ]; then
    echo $i"detected xfs - performing fsck at mount time"
elif [ $fs = ext ]; then
    draw; e2fsck -C 0 -p $1; wait; draw
else
    echo $i"detected unsupported fs - skipping fsck"
fi }

[Ed_P]

Thank you babam. Is the results of that test in the dmesg log?

Added in 8 minutes 9 seconds:
/mnt/isoloop/boot/syslinux/initrd.xz/initrd/finit lines 144-153 to be exact.

Added in 23 minutes 55 seconds:
When booting I sometimes have my save.dat file rejected for being non-writeable and the system boots with none of my saved changes. I have found that the file is non-writeable because the drive it is on is classified as non-writable. If I reboot the problem repeats, and I can not Create New Folder or Create New Document on the drive. I can boot to Windows 10 and write to the drive but not Porteus. I have found that when in Windows running a chkdsk command on the drive, NTFS, when I reboot Porteus it is writable and the save.dat file is accepted.

Added in 1 minute 48 seconds:
It would be nice if Porteus finds the drive non-writeable it would still boot with the save.dat file's changes and only post a warning that new changes won't be saved.

[Rava]

It would be nice if Porteus finds the drive non-writeable it would still boot with the save.dat file's changes and only post a warning that new changes won't be saved.

That would be a new feature.

A different option is having a cheatcode for a 2nd save.dat container - which is only valid when a 1st save.dat container is already existing and mentioned in cheatcode - the 2nd one would be tried for read/write access when the 1st one fails (1st could fail due to different reasons, see short list below). Since I not looked into how Porteus handles the use of a save.dat at boot, could be that this approach is easier to implement as your suggestion…
Also, when the save.dat file fails at boot due to corrupti 2nd save.dat containeron, that approach could automatically switch to 2nd save.dat container. Still there needs to be a visible loud info (as in bold/red or bold/yellow) when it switches to the 2nd save.dat file and the reason it did so:
* because the 1st one was on a read-only filesystem (e.g. like in your case because of dirty bits set and Windoze-chkdsk needed to fix that)
* or because 1st save.dat is corrupt

[Ed_P]

That would be a new feature.

Not a feature, a better way to handle a problem a user encounters.

A different option is having a cheatcode for a 2nd save.dat container - which is only valid when a 1st save.dat container is already existing and mentioned in cheatcode - the 2nd one would be tried for read/write access when the 1st one fails

And when would Porteus update this 2nd save.dat? And what drive would it be on, a USB drive? I have a script that backs up all my changes to an xzm module so I didn't loose anything but a new user probably wouldn't have one.

(e.g. like in your case because of dirty bits set and Windoze-chkdsk needed to fix that)

Interestingly enough, chkdsk didn't report finding or fixing any errors.

[Rava]

And when would Porteus update this 2nd save.dat?

When 2nd save.dat is used, then Port updates 2nd save.dat.
When 1st save.dat is used, Port updates 1st save.dat

And what drive would it be on, a USB drive?

Internal drive, external harddisk, external USB thumbdrive… whatever the user chooses.
What would make no sense at all is using the same partition than 1st save.dat … for obvious reasons (see your issue above)

Added in 3 minutes 13 seconds:

Interestingly enough, chkdsk didn't report finding or fixing any errors.

Does chkdsk even report about the dirty bits?
Since I no longer have any running Windoze (no XP - I have more than one valid licenses for that incl the professional CDs), nor a W7 (that I have only as licence since I never had any CD or DVD for it and without manually creating such, a broken Witless means a lost Witless) I cannot test that myself.

[Ed_P]

Found the source of the locked disk problem.

When running Windows and I close the notebook's lid and it is not plugged in and go to bed at some point Windows switches from hibernate to shutdown and locks the harddrive's NTFS partitions. In the morning I have to boot to use the system. If I boot to Windows then reboot to Porteus the harddrive's NTFS partitions are writable. If however I choose to boot to Porteus instead the NTFS partitions are locked, so I have to reboot to Windows then reboot to Porteus to get things back to normal.

Interesting.

Added in 6 hours 12 minutes 41 seconds:
I should add, the harddrive's FAT32 EFI partition remains writable.

[Rava]

^
One solution would be to add an ext3 or ext4 partition to the internal harddrive and use that for your save.dat .

If however I choose to boot to Porteus instead the NTFS harddrives are locked

Do you mean harddrives or partitions?

[Ed_P]

Do you mean harddrives or partitions?

Yes, partitions. Sorry. Fixed.

[Rava]

Added in 2 minutes 41 seconds:
aaaa

not feeling well?

[Ed_P]

A mistype that got temporarily posted for about 5 seconds!

[Rava]

^
More importantly - I deem this part that you ignored

One solution would be to add an ext3 or ext4 partition to the internal harddrive and use that for your save.dat .

much more important than that part

Do you mean harddrives or partitions?

you replied to.

[Ed_P]

More importantly - I deem this part that you ignored
:
much more important than that part

a. Windows doesn't support ext3 or ext4 partitions without some addon app added.
b. There's no quarantee the NTFS problem won't impact the ext3/4 partitions also.

[Rava]

a. Windows doesn't support ext3 or ext4 partitions without some addon app added.
b. There's no quarantee the NTFS problem won't impact the ext3/4 partitions also.

a Why do you want to have SM-Witless mess with your ext3/4 partitions? Witless lists all these as "unknown" and leaves them be. Just as planned I want it.
b I never encountered a single time when Witless changes the access right or anything else of a Linux partition that was created on the internal harddrive - and how could it when it's "unknown" to it.

I used simply gparted from a loaded-into-RAM live Linux to create a needed Linux partition - and I added a Linux Swap partition when I am at it. Such partitions never bothered Witless - unless you deem the "unknown partitions" listed in Witless listing of partitions as issue.

Remember we speak of normal harddisks here. I never had an internal SSD - look into the thread about creating Linux stuff on one of these somewhere on here if its an SSD.

[Ed_P]

a. Harddrive backups. Free space checking.
b. You ever used Windows 10 or 11? I've never encountered a single time Windows changed the access right of any partition before either, until now. Maybe it's a nvme drive thing.