XDAIIi backup size differences - MDA II, XDA II, 2060 General

hi,
I'm currently and configuring several XDAIIi's, after confugring each one I back them up using XBackup, however all teh backups are several hundred Kb's different in size, the only difference is how they're configured.
Any ideas why the backup sizes vary so much?

Related

Saving all of the phone settings

I'm coming from a Treo 650, which when it was synced saved all of the phone settings as well as the normal data exchanged when a sync is done. This came in very handy when I had to get a replacement Treo because all I had to do was sync the new phone and all of my previous settings were there.
In trying to figure out why the wi-fi on my Wizard is not working I've tried several different firmwares without any success. I'm going to take the phone to a T-Mobile store tonight to see if they'll exchange it for me. I've made a lot of configuration settings in the phone that are going to be a pain to reset again (after having done it numerous times with different firmware versions). Is there a way to backup and restore all of the phones settings at once? I assume that this would involve backing up and restoring the phone's registry. Is it as simple as copying the registry off the phone with something like Total Commander and then putting that registry back (with the same firmware and software, of course) on the new phone?
I tried spb Backup recently and it seems to restore everything. They have got a free trial for like 30 days, which should be enough for your purpose, but you need a mini SD to backup to.
http://www.spbsoftwarehouse.com/products/backup/?en
I do not know if any issues arise when you try to restore to a different device than the one the backup was originating from. I *guess* it should work alright, but you can ask the folks at spb. They seem to be pretty responsive.
HTH
Volker
Yes use spb backup, registry backup alone will not do the job. Spb backup will work fine as long as device is the same model and the ROM is the same.
Full restore
I use SPB Backup and have done several full restores. When I install software, I first do a backup, install teh software, and if it doesn't work well (an all too common phenomenon), I do a hard reset and restore, since it is hard to remove software otherwise.
No settings need changing, it is a full backup.

Storage Card Tweaks?

I have the TMOUSA version, but I think this question would apply to all versions, and in fact to other phones as well.
I was just re-reading the excellent guide to storage card optimization by the great Windows Mobile guru (and XDA member) who writes under the name Menneisys:
http://www.smartphonemag.com/cms/forum/topic/17921?&TOPIC_ID=17921
That article was written a few years ago, though, with older WM versions, and older storage cards.
I am wondering if the info is still relevant, to a new phone like the HD2, with WM 6.5 and Sense, and the newer storage cards?
The 16MB storage card that comes with the HD2, although the newer SDHC type, is only Class 2, therefore relatively slow, compared to Class 4 and Class 6 cards. I am wondering if using any of the tweaks suggested in the article by Menneisys would speed up the card.
For instance, changing from FAT32 to FAT16? (FAT16 is really ancient now though, don't know if it would work well at all on newer cards and devices.)
Eliminating the FAT backup?
Also, by changing to a larger cluster size? (Which of course, would reduce the storage space, by adding more slack. But would it speed up the card's performance enough to make it worth it?)
Of course defragmentation is always a good idea, with any disk or card, old or new. That part of his advice is not in question, then or now.
But I am wondering about the other stuff--like changing to FAT16, eliminating the FAT backup, and changing the cluster size?
Anyone know? (Menneisys, are you reading? Others?)
Thank you.
well, without reading the link, (i'll save that till the kids are in bed) i can say that fat16 can't address 16gb, however re the cluster size, yes, that can deff help, especially if you have lots of fairly large files. if your card is mostly music images and video, then you can deff benefit from setting the size as large as it will go. it does mean tiny files will take up a whole block, of course, but if its mostly big files then go for it.
samsamuel said:
well, without reading the link, (i'll save that till the kids are in bed) i can say that fat16 can't address 16gb, however re the cluster size, yes, that can deff help, especially if you have lots of fairly large files. if your card is mostly music images and video, then you can deff benefit from setting the size as large as it will go. it does mean tiny files will take up a whole block, of course, but if its mostly big files then go for it.
Click to expand...
Click to collapse
Very interesting article. Yes, do read it when you have a chance.
Yes, probably SDHC cards did not exist at the time of the article, nothing larger than 2 GB. So, sounds like the FAT16 option is out for current cards.
Do you know if that option of formatting a card with "no FAT backup" still makes sense on current cards? Is it a risky thing to do?
Regarding the cluster size-- most of us probably have both small and large files, not only one or the other. So, it is a trade-off between speed and storage space. What cluster size do you think is a good balance between the two?
never read anything about fat backup, so i couldn't say. as for block size, i use 16k on a 2gb card, which has 1gb of music and about 300meg images.
i would say the lost space is negligible on sdcards, even if you have a thousand 1k files, you only waste 16meg, so that's maybe 1/2 an mp3 album,, its only really an issue when dealing with hundreds of gig hard disks with tens of thousands of tiny system and program files. (just checked mine, theres only 250 files smaller than 32k, and only 120 less than 5k)
course, its a matter of preference, and i'm sure there are loads of people will say i'm wasting space and should be disowned from the community,, hehe
samsamuel said:
never read anything about fat backup, so i couldn't say. as for block size, i use 16k on a 2gb card, which has 1gb of music and about 300meg images.
i would say the lost space is negligible on sdcards, even if you have a thousand 1k files, you only waste 16meg, so that's maybe 1/2 an mp3 album,, its only really an issue when dealing with hundreds of gig hard disks with tens of thousands of tiny system and program files. (just checked mine, theres only 250 files smaller than 32k, and only 120 less than 5k)
course, its a matter of preference, and i'm sure there are loads of people will say i'm wasting space and should be disowned from the community,, hehe
Click to expand...
Click to collapse
Read the Menneisys article, and he says it makes the card run a lot faster, to eliminate the FAT backup. (Something you can do with SK Tools.)
However, I would wonder if that would make the card less stable, more prone to data loss. Or, even whether a non-standard cluster size might make the card more flaky?
does wm 6.5 support exfat?
using 16G thumbdrive on win 7, exfat is wayyyy faster than ntfs.
I used the 8GB card at the beginning, switched then to a 16GB card class 6 and then to 32 GB class 2 and dinĀ“t find the slightest dfifference in speed, neither when recording videos with the cam in max resolution.
me said:
Read the Menneisys article, and he says it makes the card run a lot faster, to eliminate the FAT backup. (Something you can do with SK Tools.)
However, I would wonder if that would make the card less stable, more prone to data loss. Or, even whether a non-standard cluster size might make the card more flaky?
Click to expand...
Click to collapse
lets take a step back and think about what the FAT backup is. i believe it is another table that mirrors the contents of the primary table. essentially, it can be used to recover your file system table in case the primary backup is corrupted/lost. now lets think about WHEN this table is read. to the best of my knowledge, the backup is read ONLY if the primary is found to be corrupted. similarly, the backup is UPDATED/WRITTEN only when the primary is UPDATED/WRITTEN.
thus, any speed gain due to disabling the backup should be seen in WRITE operations ONLY. read speed should be not be affected by that tweak. i could be wrong though!
if i am correct, then try disabling the backup if you desire write speed. however, you will lose some of the "robustness" of the file system. and FAT (and its variants like FAT12, FAT16, FAT32) are already fairly fragile file systems.
regarding cluster sizes, a smaller cluster size means LESS wastage when having many SMALL files. a larger cluster size means MORE wastage when having many SMALL files. however, a smaller cluster size means MORE clusters to address, which means a LARGER allocation table, which means MORE TIME spent looking up/updating the table's contents. conversely, a larger cluster size means LESS clusters to address, which means a SMALLER allocation table, which means LESS TIME spent looking up/updating the table's contents. so the sweet spot would be somewhere in the middle. HOWEVER, most modern operating systems load the allocation table in MEMORY so i imagine the speed gain would be negligible. the fact that the table is managed in memory and periodically updated back to the disk is the reason behind most corruptions in a non-journaling file system like FAT.
i've over simplified things a bit, but it should give you an idea of what kind of gains to expect by such tweaking (i.e. little to none in my opinion!).
Again, I'd suggest reading the Menneisys article.
ASCIIker said:
lets take a step back and think about what the FAT backup is. i believe it is another table that mirrors the contents of the primary table. essentially, it can be used to recover your file system table in case the primary backup is corrupted/lost. now lets think about WHEN this table is read. to the best of my knowledge, the backup is read ONLY if the primary is found to be corrupted. similarly, the backup is UPDATED/WRITTEN only when the primary is UPDATED/WRITTEN.
thus, any speed gain due to disabling the backup should be seen in WRITE operations ONLY. read speed should be not be affected by that tweak. i could be wrong though!
if i am correct, then try disabling the backup if you desire write speed. however, you will lose some of the "robustness" of the file system. and FAT (and its variants like FAT12, FAT16, FAT32) are already fairly fragile file systems.
regarding cluster sizes, a smaller cluster size means LESS wastage when having many SMALL files. a larger cluster size means MORE wastage when having many SMALL files. however, a smaller cluster size means MORE clusters to address, which means a LARGER allocation table, which means MORE TIME spent looking up/updating the table's contents. conversely, a larger cluster size means LESS clusters to address, which means a SMALLER allocation table, which means LESS TIME spent looking up/updating the table's contents. so the sweet spot would be somewhere in the middle. HOWEVER, most modern operating systems load the allocation table in MEMORY so i imagine the speed gain would be negligible. the fact that the table is managed in memory and periodically updated back to the disk is the reason behind most corruptions in a non-journaling file system like FAT.
i've over simplified things a bit, but it should give you an idea of what kind of gains to expect by such tweaking (i.e. little to none in my opinion!).
Click to expand...
Click to collapse
These tests might be of some interest to you.
http://forum.xda-developers.com/showthread.php?t=756781&highlight=card+speed+test

[Q] A Different Kind of File Corruption!

I would love to find out what could cause the following:
I bought my SGS when I was on holiday in the UK, and I used it to take a few dozen photos.
I used the highest resolution setting which gives a file size of approx 1.5MB for each jpg.
After backing them up on the 'external SD card' , I copied them to my wife's laptop, where she noticed that some of them were really low resolution.
So I checked the file sizes on my Galaxy S, and I was amazed to find that about half of the files were not the expected size.
I selected the option to list them by order of size - the first 20 or so files went from 17KB, 20KB, 35KB, 100KB, 340KB etc... then the remaining 30 or 40 files were all the correct file size, i.e. 1.4MB to 1.5MB.
None of the photos had anything missing regarding the subject, but they were just lower resolution, as though they had been somehow resampled to a smaller number of pixels.
If anyone has any idea as to how they could get corrupted like this, I would love to know.

Repartition tool ?

Hi everyone,
Am I the only one being shocked about the available data being 52.7Go, from (roughly) 59.3Go total ?
I know there might be some roms out there, CM13 and so on, but I remember repartitionning my i9100 or that old HP Touchpad to much, much smaller partitions in order to grab some space.
- Since the ZIP is around 2.2Go, let's go around 3.5Go for caching purposes : that would be 3Go won for free. And even much much more, since a 350Mo CM13 is the size the OS should take. 2200Mo for the system, for real?
So, my question is : Does somebody has the time to explain why there are so few repartition tools around for most devices (of what's I've seen/looked, seems to be about the tools/bootloaders/drivers being open enough), and if we might see that for the Axon 7 someday? I'm a freak for wasted space.
Thanks
There are so few tools in general, because if someone messes that up, there very often isn't a way to fix the phone. How many people mess up a simple flash of their phone, much less handle repartitioning their entire device?
And they can't just size the partitions to the current size, esp. for system. They have to leave space for future upgrades to allow for size upgrades. Plus, there are a lot of different partitions on the phone (32, most are small) for the various system parts that also leave some expansion room. System does seem to have to have some wasted space being sized at 6 GB but only using 3.8. But that does leave plenty of room for future system updates (and the Chinese system image is around 4.6 GB).
Companies don't often ship all of those partition images as they are usually low level factory things or phone specific. So people would have to know how to make a full backup of those and restore them.

[Q] Is there a way to transfer NookManager backups from one nook to another?

I have tried doing this before, but I get an error message when trying to install a backup that came from a different nook. It says something like there is not enough memory on the Nook, which I know is a lie. There should be identical memory taken up a ROM on one nook to one on another, right? It seems that the nooks identify which one is which by slight differences in storage size?
If I could do this, it would make passing my perfect setup from one nook to multiple nooks for friends very easy.
ALinkToTao said:
I have tried doing this before, but I get an error message when trying to install a backup that came from a different nook. It says something like there is not enough memory on the Nook, which I know is a lie. There should be identical memory taken up a ROM on one nook to one on another, right? It seems that the nooks identify which one is which by slight differences in storage size?
If I could do this, it would make passing my perfect setup from one nook to multiple nooks for friends very easy.
Click to expand...
Click to collapse
Because the backup is essentially a clone it will mismatch the MAC address and serial number. There may be other issues.
Seems to me there were some old posts about editing both of those values, but I'm not positive about that. Of course that would mean recording both before attempting the cloning process.
Sounds like it would take just as much time as just going through and setting it up manually.

Categories

Resources