This may be a little complicated but here is the basic gist:
1. Android 2.1 (B&N Nook Simple Touch)
2. I backup the dictionary files in /system/media/reference and then delete the originals. This shows a corresponding increase in the available space in /system
3. I create a symlink to alternate dictionary files in /sdcard/Dictionary (or /data/media/B&N Downloads/Dictionary--same result either way)
4. After rebooting I have access to new dictionary. Then I change my mind and want a different dictionary.
5. I delete the symlinks in /system/media/reference
6. I create new symlinks to a different dictionary, reboot, etc.
7. Now I get tired of all this and want to return to the stock dictionary.
8. I delete the symlinks in /system/media/reference and prepare to copy the stock backups to their original location.
BUT
9. I see that there is no longer enough space on /system to restore the original files! As an example, the stock available space in /system is 55906 kb (80% full--that's with the dictionary files in their normal place). After a few symlink cycles it may drop down to something like 30359 kb (89% full). Restoration of the stock dictionary requires about 57000 kb available space.
Blah-blah-blah. I've done this many times now, each time searching diligently for what is taking up the space that should be free. The only way to get the space back is to restore an earlier nandroid backup.
Surely this is not supposed to happen with symlinks? To delete one I am using adb shell rm. Is there something else I should be doing?
Why does the use of symlinks in /system gradually erode available space?
I am working on a routine for swapping dictionaries on an e-reader (Nook Simple Touch--Android 2.1). I've got the shell commands nailed down and have constructed an app using Tasker. It all works g...
android.stackexchange.com
Yep, and I did see your comment which turned out to be really helpful, @alecxs! I've solved the problem and answered my own question over at Stack Exchange.
The key is to kill the background process which is holding on to the dictionary databases before doing any file manipulations. If that is done, everything works as it should and no funny /system storage losses.
Thanks so much for nudging me in the right direction.
don't thank me, I had something different in mind. but yes, reading your answer remind me some strange behavior in 5 years old backup script:
after lazy umount + rm -rf /data still there was ~1GB disk space occupied.
this is because deleted files remain open for running processes, just the inode becomes orphaned.
killing system_server immediately freed up these 1GB and solved for me. lsof is your friend
Related
I looked for a while, and found parts of the method, but no guide....
can someone give me a link as to where i can find it?
I'm not sure that all the ROM devs are using the same code, so:
"Use the force; read the source."
On my current ROM (Aloysius V12), a2sd is a shell script at /system/bin/a2sd - 453 lines long. At the beginning of that script are the comments
Code:
# A2SD version 3
# Edited By: TrevE @ xda for damagedrom
# Based on the modded Apps2SD by Robert Travis Kirton
# Automatic ZipAlign by Wes Garner
Not the easiest read in the world, but "what it does" is right there; you just need to decipher the script.
In the Aloysius version, it becomes apparent that it just "runs" automatically (started from /init.rc). It can be configured by toggles in
/data/data/com.damaged.DConfig/dc.conf -or-
/system/etc/dc.conf
It appears from examination of that version of the script that it tries to be reversible - that is, if you turn it off with a toggle in the configuration file, the next time it boots, it will move the apps back to /data. Don't quote me on that, though; YMMV.
Make sure you have backups and test thoroughly.
bftb0
There's not much of a guide for it, but I'll try to explain it as best as I can.
Apps2SD (or A2SD) is a script originally created by Cyanogen. The script, in its basic form, does one thing: moves your applications from the internal storage (/data/app and /data/app-private) to a linux-formatted (ext2, ext3 and sometimes ext4) partition created on your SD card. The way it does that is the following:
1. Creates /system/sd/app and /system/sd/app-private directories on the ext partition of your SD card
2. Moves the programs in /data/app and /data/app-private to /system/sd/app and /system/sd/app-private, respectively
3. Deletes the /data/app and /data/app-private directories
4. Recreates the /data/app and /data/app-private entries as symbolic links pointing to /system/sd/app and /system/sd/app-private, respectively.
Over time, developers such as myself has expanded on Cyanogen's basic script (even Cyanogen has improved the script quite a bit since the original version). The program has evolved to do the following (depending on developer):
1. Moving dalvik-cache to the SD card (and even to the Cache partition in Modaco's version)
2. Enabling JIT functionality (an enhanced Dalvikvm)
3. ZipAligning programs to make them load faster
4. Changing the Dalvik heap size to minimize dalvik-cache bottlenecks
5. Enabling swap partition
6. Diagnostic functions to check if your setup is correct
7. Automated repair function
Currently, there are three popular versions of Apps2SD: CyanogenMod's version by Cyanogen (commonly known as Apps2SD 1.x, though I know it has evolved as well), Darktremor A2SD by me (version 2.x), and DamageControl's version by TrevE (version 3.x). The version numbers really don't mean anything nowdays. When I created Darktremor A2SD, I based my code from CyanogenMod's first versions (1.x). TrevE based his code from my 2.5 code. At the time, TrevE's code was the most feature-rich, but over time Cyanogen's version and my version have evolved, so now all three are close to the same features.
The way each controls the various options is different. Both Cyanogen and TrevE uses custom properties (Cyanogen starts his custom properties with cm for CyanogenMod, while TrevE uses dc for DamageControl). I use a series of files stored on /system/sd (the root of the ext partition) that control which options are loaded.
Cyanogen and TrevE's versions have GUI interfaces while mine is all terminal based commands. Theirs is easier to program, but mine is more flexible with immediate feedback (designed for diagnostics). Also, whatever roms don't work with Treve's version will usually work with Cyanogen's version. Darktremor A2SD was designed to work with most roms (whether it does is another question, but that's why it's constantly evolving as well).
Trying to keep this from sounding like I'm trying to pitch my program.
I don't know what else there is to say...if you want to ask more questions, I will be happy to answer them to the best of my abilities.
adammsu said:
I looked for a while, and found parts of the method, but no guide....
can someone give me a link as to where i can find it?
Click to expand...
Click to collapse
excellent replies, thanks you very much, both of you. That definitely clears some things up.
if i were to take what i read (from this and other things) and try to make it practical for me:
1: partition SD (after backups and what not)
2: install rom that supports
3: use one of the 3 a2sd apps (depending on rom) to move the files and set up functionality
sounds about right?
adammsu said:
excellent replies, thanks you very much, both of you. That definitely clears some things up.
if i were to take what i read (from this and other things) and try to make it practical for me:
1: partition SD (after backups and what not)
2: install rom that supports
3: use one of the 3 a2sd apps (depending on rom) to move the files and set up functionality
sounds about right?
Click to expand...
Click to collapse
Steps #1 and #2 sound about right - a2sd is already set up in them, and merely detecting an ext2 (or ext3) partition on your SD card will kick it in place.
Wiring it into another ROM that doesn't already have it is a little bit more detailed, and - because you need to start up the mounting and symlinking pretty early in the boot, part of the fixups need to be done inside the boot image. (That means that you would have to unpack the boot image, edit it appropriately, repackage it, and then flash that boot.img back to the phone). A fair bit of work.
Thankfully, the ROM devs that have everything set up for you have already done this work for you... just do steps #1 and #2... and then afterwards, make sure you understand the implications of doing regular Nand backups versus Nand+ext backups.
bftb0
I am trying to make a script that will remove the dex files for apps that have not been used in a "long" time, thereby making free space.
I just went through the "/data/data is full, apps force closing lots" again.
I did the "wipe dalvik" "fix"... but I'd like to do 2 (3?) things better.
1. Not install another app just for this. I have Tasker. I don't need/want another.
2. Free space by removing dalvik files that are old, instead of just using "rm -f *".
3. Accomplish this apparent feat of magic without having a list of "you need to install this, this and this."
What is particularly "painful" is that the solution is SUPER simple.
Code:
find /data/dalvik-cache -atime +14 -delete
EXCEPT that BusyBox does not include the "-atime" (last accessed time) option. Only last modified time (-mtime) is supported, and I that's not going to have the affect I want.
I ran "ls -lu /data/dalvik-cache" (u=order by accessed time), but the displayed times can't be correct. I emptied the directory ~9/1/2012. Now, there are files showing dates back into 2011. !?!??!!? How is that possible????
Hi
Since ever I noticed a weird thing on XMP: /cache partition is always almost empty.
Yes, I checked many times during a long time, it's like is never used.
Code:
$ df
/cache 101.5M 1.1M 100.4M 4096
I have only an empty lost+found dir and two files under recovery dir:
Code:
# ls
-rw-r--r-- root root 105 2012-12-15 02:07 last_install
-rw-r----- root root 3214 2012-12-22 10:36 last_log
For example, in a previous phone /cache was actively used by market for downloading packages before installing them.
Here on XMP I can't upgrade also small packages (40+ megs free on /data) 'cause they're downloaded in /data and fill it before being upgraded, and /cache remains always empty.
In addition, if for some reason playstore crashes while downloading a big app (30megs+), it leaves my /data (almost)full and I must remove by hand a large temporary file from /data/system.
Well, /data is used instead of /cache, 100mb wasted in this way.
Someone else finds experiences the same behaviour?
I was thinking about a linking trick to use that space (for dalvick or swap...), but I'd prefer it would be correctly used by system.
Infos: SK17i, stock .587, root, locked BL, link2sd.
Thanks, bye.
Same in Xperia Mini
Well, this isn't nice...
some ideas
Hello! I was doing several searches and come to some results:
Note: I will not try it on my phone (Xperia Mini Pro) because I'm still an apprentice to flash and modify it, and secondly I have no resources to change my phone if something goes wrong. Finally, sorry for the grammatical errors, I do not speak English natively.
The following are links taken from different forums / blogs (neither is my property).
The general idea is the same, use parted (or any similar app) to edit the partitions inside the phone.
One of the problems that arise and I have doubts about is, what is the file system of internal partitions? ext3?. is something that I have to keep reading.
This is the first blog I found where it gives a possible procedure to follow:
http://aarondiep.blogspot.com.ar/2011/11/resize-partition-on-android.html
Here's a post where one of the users that modify his partitions and, later, returned to stock status.
http://www.droidforums.net/forum/htc-droid-eris/78650-internal-storage-partitions-screwed-up.html
Here is a guide on how you use parted (includes screenshots) BUT IT DOES WITH THE SD CARD
http://mobilecon.info/how-to-partition-sdcard-using-parted-partition.html
Finally, a tool for YAFFS2 file system:
http://forum.xda-developers.com/showthread.php?t=1645412
I hope these links are useful. I really would like to use optimally all the hardware of the phone.
Exitos!! :laugh:
Hi!
Thanks for your interest!
Resizing partitions, I read time ago, is a really critical operation.
I expect to have /cache partition as it has been made, the problem is that apps do not use it!
Resizing that block device to, let's say, zero, would give space to other partitions, but we'd lack a cache.
I definitely believe one of master questions is: where the hell does playstore download packages before installing?
During a big upgrade (let's say angry birds Rio 30+ megs) with df I only see /data growing (and /cache always empty), but after a lot of searching for newest and biggest files (busybox ls -ltrh, busybox ls -Shl) I could not find where they are put.
Once found this download location (no, it's not /data/data/com.android.vending/cache/main), would be easy to bind /cache to this dir.
Apk files from Google Play is downloaded to: data/data/com.android.providers.downloads/cache/
Wysyłane z mojego SK17i za pomocą Tapatalk 2
Hi
Many thanks for this tip!
Well, it's true apk are downloaded there.
BUT I see a strange behaviour: when I recieve the "low memory" (space on /data partition) notification, the apk suddenly disappears! :what:
In logs I see a lot of "couldn't openat chache: no such file or directory" immediately before low space notification log line...
You can use cache as swap if your kernel support it..
Sent from my Walkie'Talkie
Hi
Well, i symlinked /data/data/com.android.providers.downloads/cache to /cache/cache, and the partition is now correctly used by play store.
Is really strange that this is not a system default, btw.
EDIT: the /cache/cache was regularly erased by system, I symlinked /data/data/com.android.providers.downloads/cache to /cache and all is ok now.
EDIT2: you must previously remove (rmdir) the existing /data/data/com.android.providers.downloads/cache!
Could you put the exact command?
luchoz said:
Could you put the exact command?
Click to expand...
Click to collapse
Code:
ln -s /data/data/com.android.providers.downloads/cache /cache
:good:
thank you!!
would use XD
New info!!
http://forum.xda-developers.com/showthread.php?t=1959691
Really interesting
I didn't search too thoroughly for the answer to this question, but I can't imagine that I'm the first asking it:
In fiddling around with adb backup and the Android Backup Extractor, I noticed that all it really seems to do is pull the Shared Preferences, Internal Storage, and SQLite Databases from every /data/data/<app>/ directory and unnecessarily box and encrypt them together (if you've encrypted your phone like I do) into a tight little package. Worse, it seems not to catch everything (like com.android.providers.contacts where your address book lives). If I simply run
Code:
adb pull /data/data localBackup
I get all of the SP, IS and SQLDBs - with the caches - from all of the apps, but with the benefit of it not being stuck in an over-wrapt file and knowing that I've gotten every app. My phone is rooted but does one need root access to do this from ADB?
I have two questions:
What advantage does adb backup have over adb pull /data/data? The latter seems much safer (as in it's easier to check if it's been done properly) and restore (simply push the pulled data back into its folder)
What user settings and/or information is not included in /data/data, aside from the obvious data on the /sdcard? Put another way, would a copy of /data/data and /sdcard be a sufficient backup of all of my phone's data? (notwithstanding needing to reinstall the original APKs and ROM)
I had been flashing a rom onto my phone (RR 8.0) and customarily had taken a TWRP nandroid backup of the existing rom (RR 7.1.2). Then when I went to wipe data, cache, system, I had accidentally checked the internal storage too and wiped it as a result. At this point all I could do was flash the rom, then magisk root and busybox, then I cloned internal storage (which I identified using cat /proc/partitions to be block sda18) using ADB and Cygwin (with the netcat package) thus:
Code:
TERM-1
------
adb forward tcp:5555 tcp:5555
adb shell
su
/system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox dd if=/dev/block/sda18
TERM-2
------
adb forward tcp:5555 tcp:5555
nc 127.0.0.1 5555 | pv -i 0.5 > sda18.dd
Couple hours later I end up with ~23.5 GB of raw partition dump (all 24,649,728 blocks of sda18 copied, I checked). Now most file recovery software (Testdisk, PhotoRec, [email protected] products) I've tried seem to check for file signatures/extensions, naturally TWRP's backups aren't among them.
TL;DR: All I need at this point is one file in particular: data.ext4.win?? – the backup of the data partition, hope I got that extension right – by a data recovery software that can hunt those very few backup files from a cloned internal storage image.
(No, partition recovery is no good.)
Clearly these files are still out there among the sectors because all that I'd done to internal storage was a format. Having come so far I find it hard to believe there isn't software that can find TWRP backup files due to its variable filetype extension. I would assume the file signature is that of TAR files, but I'm not sure.
Recovering these backups is important to me because trying to recover files from the data partition, for example, ends up returning nondescript, unlabeled data by the thousands, no way to know which file is which (looking at you, Photorec). Restoring a backup would return the data partition exactly the way it was before it was wiped out. The rest of what used to be the contents of my internal storage are not important to me. I have over 2,000 contacts that were not backed up to any online or offline service, which most definitely resides in that backup file. Please help me with some legitimate solution or suggestion rather than to say it won't be possible – no reason to believe so when I have the cloned image of the internal storage – at the very least a data recovery software that can help me get those deleted backups out ASAP (my business relies critically on those contacts and chat app histories). Time is of the essence here, I humbly request the community's help urgently.
PS I realize this question has more to do with forensic data recovery but I'll still give it a shot in here. Hope this post isn't too vague in stating what I want done. I'm sure this would massively help others in the future too, given how common such an occurrence is.
The problem is not only did you format it but when the system was setting up it also altered it. So the data maybe gone and anything that could find it is beyond the skills found on this forum these days.
zelendel said:
The problem is not only did you format it but when the system was setting up it also altered it. So the data maybe gone and anything that could find it is beyond the skills found on this forum these days.
Click to expand...
Click to collapse
I don't deny that. But assuming data written is sequential only 30-50 MB would've been written since. And the backups were taken when the internal storage already had around 8-9 GB of other data. Which I believe should mean that there's still a chance that the backup files weren't overwritten.
Although now that you mention it I'm beginning to have my doubts, considering wear leveling patterns for NAND flash memory...
PS Photorec identifies twrp backups as tar files with wrong extension but that doesn't seem to recover anything anyway. I guess you're right :'(