Notices

I want a program to make it so /home and Mydocs will grow or shrink according to the usage, sharing the same free space.

One way i picture it working would be to have both partitions actually be files in a third partition, those files would grow and shrink, and the program would insert "false" information about the free space on each partition representing how much space is left in the third partition; this program would probably need to kick in quite early during boot process since /home has things that are necessary for booting (or so i've been told) . If the file systems in question don't work well with being resized frequently, instead have the those virtual partitions believe they use all the memory (twenty somthing gigs), and have a file inside them that has a few MBs less than the currently avaiable free space, the file wouldn't actually be occupying any space but the partitions would react is if it was, measuring free space would be done by checking the size of the file and adding tot he reported free space so it wouldn't show true free space in most programs, having a bit less than the actual free space will help with fast writes providing a buffer of free space that is always avaible so programs won't think there is no more free space untll really there is no more free space; the size of the buffer should be configurable so if a bigger buffer is necessary (like for downloading disk images with a few gigs) it will show it has enough space for that.

Regardless of how ti's done, it is important that it works when booting, works when plugging into USB, and doesn't loose data much less brick the device when flashing (and if possible is easy to reactivate after reflashing).

Sorry, but having a file system in a partition or hidden in a file doesn't make much difference. How would you shrink a file, if the file system in the file is making use of most of the file but there are a hole in the middle of the file system - and hence in the middle of the file?

Your concept would require a lot of file move operations - something that wears down the flash and also may brick your unit or at least lead to file loss in case it runs out of batteries or hangs at the wrong time.

The way you normally do growable file systems on a server is by using a volume manager. A volume manager virtualizes the hardware by using one or more hard disks and splitting into many smaller blocks. A file system is then created from n such blocks. When the file system needs to grow, you pick up a couple of more blocks - from same physical media or on another media and allocates to the file system.

This means that a single HDD can contain multiple partitions and free space. The free space will be allocated as needed without need to shrink any other partition. And if the first disk gets full, you can add a second disk and add to the volume manager - it will then take blocks from the second disk to grow partitions as needed. Because of the virtualization, the file system will not know that some of the data is on one physical disk/memory card and some data on another.

But a volume manager still can't in an easy way perform automatic shrinks, because the blocks that gets added to a partition is not emptied one at a time when you remove files. The file contents are spread out all over the file system. You would need to do something similar to a disk defrag to move the files in the partition into continuous chunks. This can obviously be done, but a battery-operated unit is not a good platform for such a mess.

In the end, you are asking the basic question: "please help me make a mess of my phone so I'm sure I will get a huge nose bleed when I least expect it." You - and a number of other people - are asking for a solution that is worse than the problem you want to solve.

Symlinks allows us to move large files somewhere else and just have a symbolic llink to point from the orignal location to where the data got moved. Yes - you may have to invest a bit of manual labor. But you will not be surprised in the same way, as long as you respect the mount order of partitions and don't move a file that is needed early in the boot process to a partition that gets mounted late.

Allowing files to be added/removed anywhere on the physical media without getting stuck by partition sizes is best handled by a single partition. But a single partition does have other problems. You must decide on a single file system type. And you can't reformat just part of it. And a broken file system will break more of the functionality. And you will require some other mechanisms for quota handling, to make sure that user files doesn't break some system functions by consuming the last of the disk space.

Practical solution: clone your OS to SD card. Use the internal storage as a data partition.

Concept you are describing: http://en.wikipedia.org/wiki/Logical_volume_management

Additionally you can probably have /usr or /home or /opt on a separate partition and symlinked to your / partition. However the trick with this is the mess of FAT32 + EXT3 meshed together in Maemo and FAT doesn't support symlinks among other problems.