Join Us!

Unallocated vs Free...
 
Notifications
Clear all

Unallocated vs Free Space  

  RSS
bjh505
(@bjh505)
New Member

Hello

So I am noticing that in various locations across the internet people are using unallocated space and free-space synonymously. What is the general consensus here?

I have always associated unallocated space with space on a hard drive that is not part of a file system and free space as space that is available to be written or over-written if a file previously resided there(as far as an OS is concerned). So I will pose it another way.. if I delete a file from my desktop and remove it from my trash bin is it then unallocated space, free space, or both?

I have a follow-up question but I would like to see some peoples thoughts on this, thanks!

Quote
Posted : 10/02/2020 7:56 pm
tootypeg
(@tootypeg)
Active Member

that data would now be unallocated

ReplyQuote
Posted : 10/02/2020 8:23 pm
Rich2005
(@rich2005)
Active Member

I could be wrong, but I'm guessing this may come from EnCase using the term Unallocated Clusters, and ended up common parlance (that's what it called all the aggregated unused/no-longer-used space within a volume).
I could see why that makes sense, in that it's not completely free space, as it's part of a volume, but just not allocated to a file within the index of the volume. Free space being that which is completely free and not within a file-system (referred to as unused disk area I think in EnCase, off the top of my head, been a while now since I've used it).
On the other hand, you could reverse that logic, something that's not assigned to a file-system is unallocated, and the non-used area within a volume is free space 😉

I'm not sure there's a right answer on this one (who decides!).

ReplyQuote
Posted : 10/02/2020 10:02 pm
watcher
(@watcher)
Member

Usually the context will tell you how the the word "unallocated" is being used, but it is often used both ways.

For example a discussion involving unallocated verse slack would be using unallocated to mean file system space not currently assigned, such as a deleted file.

Running gparted to examine partition layouts would show unallocated as indicating drive space that is not part of any partition.

ReplyQuote
Posted : 11/02/2020 4:24 am
athulin
(@athulin)
Community Legend

I have always associated unallocated space with space on a hard drive that is not part of a file system and free space as space that is available to be written or over-written if a file previously resided there(as far as an OS is concerned).

The 'unallocated' always raises the question 'by who or what?' There are multiple mechanisms, so ambiguities are easy to stumble into. Here are some possibilities

1. unallocated by partition management, and thus available for creating a new partition

2. allocated to a partition, but unused by volume management – this may also be referred to as some form of slack space allocated on one level (to a partition), but unused by the next lower level (not included in the volume created in that partition).

3. under volume management control (and thus allocated for the use of a volume), but at present not assigned to a file system entity.

4. Assigned to a file extent (i.e. it's some part of a cluster – or smallest allocatable unit on a volume, which in some file systems may be parts of a sector, as for ISO 9660), but currently not utilized (this is also a kind of slack space).

… and we may continue down the hierarchy if we want to. In an emulated disk, used by a virtual machine, the sequence can be repeated and in these cases, context/focus becomes very important to establish

(Slack space has been the subject of at least one major thread here.)

In most cases, the context is clear, and disambiguation is usually not necessary.

So I will pose it another way.. if I delete a file from my desktop and remove it from my trash bin is it then unallocated space, free space, or both?

Yes.

Unallocated to a file, but allocated to a volume as well as a partition

Free for use by a new file, but not free for use by another volume or partition. (Unless you have some really fancy dynamic volume/partition system.)

ReplyQuote
Posted : 11/02/2020 6:24 am
jaclaz
(@jaclaz)
Community Legend

Let's try to draw a line.

Free space is what you can actually see in many OS tools, it means "available space that can be written to".

When you start from a wiped device and create for the first time a filesystem, all the free space is made of 00's.

Unallocated is *whatever* is not allocated, usually (but not always) if within the filesystem it is the same as "free space", but there may be exceptions.

Belong to "unallocated" also the various forms of "slack" both within and outside the filesystem or volume, JFYI a tentative of slack definition is here
https://www.forensicfocus.com/Forums/viewtopic/t=9374/

In a nutshell
1) Free space = Space that is not allocated and accessible by the OS filesystem tools
2) Unallocated *anything* that is not allocated
3) Free space < Unallocated

jaclaz

ReplyQuote
Posted : 11/02/2020 12:18 pm
thefuf
(@thefuf)
Active Member

Let's try to draw a line.

Free space is what you can actually see in many OS tools, it means "available space that can be written to".

When you start from a wiped device and create for the first time a filesystem, all the free space is made of 00's.

Unallocated is *whatever* is not allocated, usually (but not always) if within the filesystem it is the same as "free space", but there may be exceptions.

Belong to "unallocated" also the various forms of "slack" both within and outside the filesystem or volume, JFYI a tentative of slack definition is here
https://www.forensicfocus.com/Forums/viewtopic/t=9374/

In a nutshell
1) Free space = Space that is not allocated and accessible by the OS filesystem tools
2) Unallocated *anything* that is not allocated
3) Free space < Unallocated

jaclaz

Okay. How would you call sectors with data from a previous file system existed on the same device, but marked as allocated by a current file system (not available for allocation anymore) and being part of active data of a system file (if you read this file, some sectors will contain data from a previous format)?

ReplyQuote
Posted : 11/02/2020 12:24 pm
Rich2005
(@rich2005)
Active Member

As I say……I think this is a "the sky is blue" versus "the sky is black" argument.

ReplyQuote
Posted : 11/02/2020 12:31 pm
jaclaz
(@jaclaz)
Community Legend

Okay. How would you call sectors with data from a previous file system existed on the same device, but marked as allocated by a current file system (not available for allocation anymore) and being part of active data of a system file (if you read this file, some sectors will contain data from a previous format)?

If I get it right, they are allocated (now).

The fact that they contain not what the filesystem believes they should is another matter, if you prefer they are a form of steganography, they do not "belong" to either unallocated (as they are actually allocated) nor to free space (as they are actually allocated).

More practical example
In the current filesystem sectors LBA 2125857 up to LBA 212585865 (8 sectors by 512 bytes each) belong to the cluster (say) #9857 (4 KB clusters) and are allocated in the current (NTFS) filesystem as \myfake.txt with exactly 4096 bytes size.

When you open \myfake.txt with notepad you discover that it actually contains non ASCII characters and when you re-open the same \myfake.txt file with a hex viewer/editor you find out that the contents is (say) the bootsector and 7 following sectors coming from a previous logical volume formatted by DOS in FAT32.

What gives? ?

Or I am misunderstanding you? ?

jaclaz

ReplyQuote
Posted : 11/02/2020 12:39 pm
thefuf
(@thefuf)
Active Member

That doesn't make sense. This data, by its nature, doesn't belong to a current file system (it was created before the format), but it's listed as allocated (and as active file data) by that file system.

A test image is here https://github.com/msuhanov/ntfs-samples/blob/master/ntfs-ptrn.raw.gz

Check the following data streams of the "/$Extend/$RmMetadata/$Repair" file "$Corrupt" and "$Verify".

This image was filled with the "PTRN" byte pattern prior to the formatting.

ReplyQuote
Posted : 11/02/2020 12:48 pm
jaclaz
(@jaclaz)
Community Legend

That doesn't make sense. This data, by its nature, doesn't belong to a current file system (it was created before the format), but it's listed as allocated (and as active file data) by that file system.

A test image is here https://github.com/msuhanov/ntfs-samples/blob/master/ntfs-ptrn.raw.gz

Check the following data streams of the "/$Extend/$RmMetadata/$Repair" file "$Corrupt" and "$Verify".

This image was filled with the "PTRN" byte pattern prior to the formatting.

I still don't understand, you seemingly intentionally made a filesystem "hiding" some data (this is steganography).

The file "$Corrupt" is 2097152 bytes in size and occupies a single contiguous extent starting on cluster #38 up to cluster 549 included (550-38)=512*4096=2097152
The file "$Verify" is 307200 bytes in size and occupies a single contiguous extent starting on cluster #550 up to cluster 624 included (625-550)=75*4096=307200

In LBA sectors, that is LBA 432 to 4528 and 4528 to 5128.

The extent from LBA 432 to 4528 is allocated to file "$Corrupt".
The extent from LBA 4528 to 5128 is allocated to file "$Verify".

Both are allocated (and thus not unallocated).

Both are allocated (and thus not free space).

Both contain (not everywhere but in spots) sectors with the pattern "PTRN".

Again, what gives? 😯

If you are saying that it is possible that currently allocated extents may contain remains of previous filesystems or even possibly "deleted data", that is perfectly fine ) , maybe a "better" example could be a particular case of use of the hibernation, see here
https://www.forensicfocus.com/Forums/viewtopic/p=6595349/

still I see nothing connected to unallocated or free space.

jaclaz

ReplyQuote
Posted : 11/02/2020 1:54 pm
thefuf
(@thefuf)
Active Member

you seemingly intentionally made a filesystem "hiding" some data (this is steganography).

No, I just formatted a virtual drive.

Both contain (not everywhere but in spots) sectors with the pattern "PTRN".

Which is actually unallocated data (aka free space) by its origin! It _was_ claimed by a file system, but this file system is no longer there. A current file system has nothing to do with this data (unless it's overwritten), except that it marked these sectors as belonging to allocated clusters.

From a practical point of view, this remnant data wouldn't be extracted as unallocated by common tools (like blkls). But it can contain a smoking gun.

ReplyQuote
Posted : 11/02/2020 2:18 pm
jaclaz
(@jaclaz)
Community Legend

From a practical point of view, this remnant data wouldn't be extracted as unallocated by common tools (like blkls). But it can contain a smoking gun.

Sure ) , as the extent is NOT unallocated, but rather allocated (at the current filesystem).

A sector-level carver would find its contents allright, an unallocated one won't as it is NOT unallocated.

But before being unallocated (in the previous filesystem) the extent must have been allocated (still in the previous filesystem) in order to have (meaningful/relevant) data in it.

So it would be meaningful to call those re-allocated or ex-allocated extents, but they are anyway subsets of the (currently) allocated.

jaclaz

ReplyQuote
Posted : 11/02/2020 5:39 pm
Share: