Partition full, no warning?

[pythonjosh]

My +AVI partition isn't read correctly in HDDManager (hasn't in years). So I have no idea how full it is, or how big it is. It still works in every way. So I made another partition with the minimum 128mb partition size. In order to reproduce what is/should happen in the event the partition gets filled. So I attempted to copy a 350mb avi file into the newly created 128mb partition and the system crashes. As soon as the Written Total gets to near the amount of free space, the screen freezes.
Is there any error handling that should warn or prevent this from happening?

[dlanor]

My +AVI partition isn't read correctly in HDDManager

That could either be due to corruption, or due to a problem I fixed in the new release I made tonight. I can't guarantee anything, but it's worth trying anyway.

(hasn't in years).

If it really has been years, then it must be due to corruption, since the problem I mentioned fixing above was introduced in v4.23.

So I have no idea how full it is, or how big it is.

That should not be dependent on the HddManager only. Whenever you enter an HDD partition using the uLE FileBrowser, the free size of that partition should be displayed near the top right corner of the screen, on the line below the LaunchELF title with the version code. This info should be continuously updated for each file operation you perform, and should be displayed no matter what folder level on that partition you browse to. It is only during an ongoing file operation that this size info disappears from screen, as it would not reflect the true free size then.

However, some types of corruption can make this size calculation fail, in the same way as for the HddManager.

It still works in every way. So I made another partition with the minimum 128mb partition size. In order to reproduce what is/should happen in the event the partition gets filled. So I attempted to copy a 350mb avi file into the newly created 128mb partition and the system crashes. As soon as the Written Total gets to near the amount of free space, the screen freezes.
Is there any error handling that should warn or prevent this from happening?

Not at present, and the only thing we can implement would probably not be to your liking.

The only way to do it is to trust in the ZoneFree and ZoneSize values returned by the fileXioDevctl subfunctions for that specific partition. But that is the same method used for calculating the free size info displayed in FileBrowser and HddManager, so if those displays can go crazy due to corruption, then the 'safety' function you want would suffer from the same problem.

The total effect of that would be to either refuse further write access even though real free space remains (though not shown as free due to the corruption), or to permit writing even after the partition is full (as corrupted freesize info may show imaginary space).

So assuming random distribution, there would be a 50% chance of losing writability to any partition having that problem... Is that really what you'd want ?

I do intend to improve the methods of recovery from HDD write errors and such, but for cases where a freeze occurs in a driver, there is really nothing I can do.

Btw: I'm not sure if you already know this or not, but WinHiip does have a command to use for cleaning up some forms of corruption. Again there is no guarantee that it will help you with your problem, but it is another thing worth trying.

Best regards: dlanor

[pythonjosh]

my AVI partition was created < 4.12. We have discussed the incorrect size problem before and was told to reformat the drive. Haven't been able to do that as of yet.

I have just counted the used space by counting the filesize of each file in the AVI partition. Totalled 62,128mb / 60.7gb. HDDManger is reporting PFS Size as 20096mb, Used -38453mb, Free 58549mb. With this much space I've counted, is it at all possible that the +AVI partition has overspilled it's 20096mb (assuming it's correct, I can't remember what I set it to when I expanded it prior to 4.12) into other clusters, making those overspill clusters unprotected from being overwritten?

I'm thinking I can make another partition (using 4.30) and copy the contents of +AVI into it, delete the +AVI partition, and rename the extra partition to +AVI. What's your input on this idea DLanor?

[pythonjosh]

In my anxiety, I went ahead and did it. I'll let you know!

[dlanor]

my AVI partition was created < 4.12. We have discussed the incorrect size problem before and was told to reformat the drive.

Reformatting is the only thing that is 100% sure to eliminate the corruption, though unfortunately it will also eliminate all the data on the drive.

Haven't been able to do that as of yet.

I'd definitely recommend backing up any unique data first.

I have just counted the used space by counting the filesize of each file in the AVI partition. Totalled 62,128mb / 60.7gb. HDDManger is reporting PFS Size as 20096mb, Used -38453mb, Free 58549mb.

All these numbers show is that they can't be relied upon, since their relationship to the really used amount is insane.

With this much space I've counted, is it at all possible that the +AVI partition has overspilled it's 20096mb (assuming it's correct, I can't remember what I set it to when I expanded it prior to 4.12) into other clusters, making those overspill clusters unprotected from being overwritten?

With corruption in unlucky forms anything can happen, but we don't have any basis for a reasonable guess as you can't remember the original size.

I'm thinking I can make another partition (using 4.30) and copy the contents of +AVI into it, delete the +AVI partition, and rename the extra partition to +AVI. What's your input on this idea DLanor?

Deleting the partition would of course eliminate any corruption inside it, but that doesn't seem to be the problem here. If that partition really has come to store file data in sector blocks not belonging to it, then we have a more serious problem that crosses partition boundaries. Deleting such a partition could make blocks 'officially' belonging to other partitions also be counted as free blocks etc

Also, with corruption of a global nature, not just affecting the area that really belongs to the corrupted partition, there is no way to fully rely on a backup involving so much data, and there is also no practical method for verifying such a backup, since both source and destination reside on the same corrupt HDD...

The only safe form of backup would be to either copy the stuff to a USB HDD (too slow), or to a PC using host: (still slow). But you'd need to do it not just for that partition, but for all of them (extracting HDL games to ISO files instead), so you can reformat the drive.

If you do want to try eliminating corruption without reformat, backing up only the definitely corrupted partition, and only using the same HDD for it, then I suggest that you do it like this:

1: move the HDD to a PC and use WinHiip to clean any corruption it can handle
2: move the HDD to the PS2 and use HddManager to create a new partition of sufficient size
3: use FileBrowser to copy the entire contents of the bad partition to the new one
4: use HddManager to remove the bad partition
5: move the HDD to a PC and use WinHiip to clean any corruption it can handle
6: Move the HDD back to the PS2 and cross your fingers hoping that the corruption is gone
(Some corruption may still be lurking, even if it's not obviously visible.)

Note that there is a possibility that the corruption will cause lockup during the backup, in which case I see no other way to 'uncorrupt' it other than a full reformat.

Best regards: dlanor