RISC OS Open: Forum: Self-extracting HD problem?

Jan 20, 2012 12:41am

The tar.bz2 version of the 19th Jan HD image extracts fine but the self-extracting one throws up a message for me at about 47%, reporting that “This item is locked to stop changes being made to it” – it’s being extracted into a new directory. Seems to be able to create a partial !Boot.

Tried from command line for good measure, but same error.

Jan 20, 2012 7:08am

Andrew Daniel (376) 76 posts

This worked correctly for me Gavin. I ran it late last night on RPCEmu running OS 4.02 and everything extracted alright.

Jan 20, 2012 7:52am

Rik Griffin (98) 264 posts

Are you trying to extract over the top of existing files?

Jan 20, 2012 8:33am

Trevor Johnson (329) 1645 posts

Are you extracting to the RAM disk? (It’s much quicker and there won’t be any issues with overwriting existing files.)

Jan 20, 2012 12:29pm

Gavin Smith (1413) 95 posts

I’m extracting into a blank directory – I’ve tried downloading it a couple of times (before I went with the tar.bz2 file which is fine for me). I tried it in 3.7, 4.02 and 5.19, just for good measure.

It’s obviously a problem at my end then. I assume it’s because the drive isn’t enabled for long filenames and it’s trying to overwrite something that it’s just written. If that’s the case, I don’t understand why the tar.bz2 file extracts fine.

Jan 20, 2012 1:19pm

Steve Revill (20) 1361 posts

The only way this can happen is if the object that it is trying to extract from the archive is already in the place where it’s extracting to, and is locked. How are you running the self-extracting archive? Where is it located when you do so?

I should add that I did make changes to CreateSEC (hence the HardDisc4.util) to remove the bug which could cause “Unable to move memory” errors and such like. It’s just possible I’ve introduced a bug – but I did test the self-extracting HardDisc4.util quite a number of times during this work.

Jan 20, 2012 1:31pm

Steve Revill (20) 1361 posts

It’s obviously a problem at my end then. I assume it’s because the drive isn’t enabled for long filenames and it’s trying to overwrite something that it’s just written. If that’s the case, I don’t understand why the tar.bz2 file extracts fine.

That sounds like a plausible explanation. The reasons why the tar.bz2 version might not do this are two-fold: 1. the untar program might not obey the permissions on the files/directories and doesn’t create things locked or 2. the untar operation ‘forces’ the extraction over locked objects.

Self-extracting HD problem?

Reply

Search forums

Social

ROOL Store

Donate! Why?

RISC OS IPR

Description

Voices

Options

Jan 20, 2012 12:41am Gavin Smith (1413) 95 posts	The tar.bz2 version of the 19th Jan HD image extracts fine but the self-extracting one throws up a message for me at about 47%, reporting that “This item is locked to stop changes being made to it” – it’s being extracted into a new directory. Seems to be able to create a partial !Boot. Tried from command line for good measure, but same error.

Jan 20, 2012 7:08am Andrew Daniel (376) 76 posts	This worked correctly for me Gavin. I ran it late last night on RPCEmu running OS 4.02 and everything extracted alright.

Jan 20, 2012 7:52am Rik Griffin (98) 264 posts	Are you trying to extract over the top of existing files?

Jan 20, 2012 8:33am Trevor Johnson (329) 1645 posts	Are you extracting to the RAM disk? (It’s much quicker and there won’t be any issues with overwriting existing files.)

Jan 20, 2012 12:29pm Gavin Smith (1413) 95 posts	I’m extracting into a blank directory – I’ve tried downloading it a couple of times (before I went with the tar.bz2 file which is fine for me). I tried it in 3.7, 4.02 and 5.19, just for good measure. It’s obviously a problem at my end then. I assume it’s because the drive isn’t enabled for long filenames and it’s trying to overwrite something that it’s just written. If that’s the case, I don’t understand why the tar.bz2 file extracts fine.

Jan 20, 2012 1:19pm Steve Revill (20) 1361 posts	The only way this can happen is if the object that it is trying to extract from the archive is already in the place where it’s extracting to, and is locked. How are you running the self-extracting archive? Where is it located when you do so? I should add that I did make changes to CreateSEC (hence the HardDisc4.util) to remove the bug which could cause “Unable to move memory” errors and such like. It’s just possible I’ve introduced a bug – but I did test the self-extracting HardDisc4.util quite a number of times during this work.

Jan 20, 2012 1:31pm Steve Revill (20) 1361 posts	It’s obviously a problem at my end then. I assume it’s because the drive isn’t enabled for long filenames and it’s trying to overwrite something that it’s just written. If that’s the case, I don’t understand why the tar.bz2 file extracts fine. That sounds like a plausible explanation. The reasons why the tar.bz2 version might not do this are two-fold: 1. the untar program might not obey the permissions on the files/directories and doesn’t create things locked or 2. the untar operation ‘forces’ the extraction over locked objects.