Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

zaq1xsw2cde3vfr

macrumors newbie
Original poster
Problem

Unable to automatically manage unwanted files and file parts, during the decompression process.

Purpose: for the practicality, efficiency, and dissolution of unneeded storage space allocation.

Current software affiliations:

e.g. Stuffit Expander.

Problems with current techniques of decompression:

If file downloaded exceeds half of storage space remaining, file cannot be decompressed.

Further details:

If any solutions are not present, there is a willingness to be informed on how to construct them.

If any more information is required for inquiry, it will be posted upon the response that informs as such.
 
You cannot delete archive files as you extract them. Any program that does that is actually removing the file just after the extraction is completed. This is both for safety (loss of data if something goes wrong), as well as just being a pain in the ass (to say the least) to do when you consider how file systems and hard drives work. Cutting bits of a file off essentially require the file being rewritten to a new part of the disk before the original space it was occupying being marked as "empty".

At least that's my understanding of the situation.
 
Concepts concluded: apologies for the delay in reply, there were deciding forces made

You cannot delete archive files as you extract them.

Incorrect: the position would be for the file itself to recompile the format required, in order to be reread by the system, processed and interpreted.

Example: [File part example = a] [File part decompressed = b] [File part deleted = c] [Software = d]

b+d = b+a

c=b

Product = a.

Simple.

Any program that does that is actually removing the file just after the extraction is completed.

There is an option within the Stuffit application that allows the entire file archive to be removed, just after a full extraction.

If that's possible, then being able to process each part, and at the same time removing each part of the archive, as small as possible (binary), would be palpable to be a possibility as well.

This is both for safety (loss of data if something goes wrong),

As each piece of binary is removed, no binary is lost: as it has been replaced by the binary extracted, found in the extraction bundle.

If anything happens during the process that causes an error or a loss of ability to extract the file, then the countermeasure would be to reassess the extraction, and revert the extraction bundle back into a compresssed archive file.

No data is lost.

as well as just being a pain in the ass (to say the least) to do when you consider how file systems and hard drives work.

The way file systems and hard drives work, allow a palpable level of capacity, in order to perform such measures.

If the hardware and file systems are incompetent enough to be unable to do the measure proposed, then they are obsolete, and need to be replaced.

Cutting bits of a file off essentially require the file being rewritten

It's a transplant: no process has to be made in order to establish a condition, as a condition already exists to refer to. This condition is then transitively reassessed, as each part of extraction gets replaced into the bundle.

The only reconditioning is in the decompression itself, which can be done anyway (as already demonstrated by the software already available).

Yes, binary has to be reapplied to another order on the storage, within the given capacity, but nothing is created or destroyed within the drive itself.

Rewriting? The technique should be described as remolding.

to a new part of the disk before

Before? No, this is not a palpable concept. As and when the processor has sent the transmission to manifest an ordered object within another position of storage, the processor should as soon as possible apply a transmission to inform the data within the archive that is in transit, to be removed.

This can be done virtually instantaneously, without any corruption to the hard drive, or removal of data within the rest of the hard drive.

the original space it was occupying being marked as "empty".

It's simply the processor making as many trips as possible within the storage device, in order to submit to the demands of the space available.

If processors can be made to work involved in any form of transmission, then they can do the optimum to achieve the result required.

At least that's my understanding of the situation.

Your understanding of the situation has a lot to be desired.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.