I want to ask. Is there inside lumias or any other WP7 a 15gb!! Partition?
If there is any, can it be accessed and are all things in there useful?
I am asking maybe the partitions can be rewritten and use that space to make our saving space for apps and photos bigger.
Thanks
Sent from my Lumia 710 using XDA Windows Phone 7 App
of course there is, but it have been used by OS
and the lumia 710 is 7G
I guess its possible to create another partition on the NAND. The problem is that you have to remove the space from the OS partition, so the space available for WP decreases. But theoretically it would be possible. However I heard that Windows has some issues with multiple partitions on removable devices.
So the OS is 15 gigs? Sounds very very large for a phone OS. Ok the question is, is it all useful, can't we reduce in size and add up the freed space to end user data storage by repartitioning the whole system.
@dewe what do you mean 7g? You mean 8gb storage?
Sent from my Lumia 710 using XDA Windows Phone 7 App
The 15gb partition contains both the system and user data, so you will get less space in WP7 by resizing it.
Related
Hello all,
i have around 10 Files with the name above in my XDA some of them with a size of 260k and some with 1,65Mb. What are they good for or where are they from.
I can´t delete them and I don´t see them in the memory usage.
regards
miba
Huge MsgQueue.. files in Windows directory
I have the T-Mobile Pocket PC with just the built-in 32MB of RAM (256MB SD card on order...)
In my case there are a bunch of MsgQueue-blah-blah files in the Windows directory, 7 of which are 1.65MB each. Plus a 3.83MB file called "rsupgrade.cp64". That's about 15MB.
Unfortunately I don't have an answer, only an additional question... hopefully someone can answer us both.
Are these eating into my RAM or am I seeing files from ROM? I suspect RAM since they change periodically. Are they critical or can I delete them? If the latter, is there a way to limit their size or prevent them from reappearing?
T-Mobile Customer Care level-3 support was relatively clueless as usual, but they did suggest that I could do the following to determine how critical those files were:
1. Perform a backup
2. Do a hard reset
3. Check and see if the offending files went away
4. Restore from backup
If the files went away, then supposedly you should be able to delete them yourself if/when they reappear later. But realize that's just the CC guy's theory, and he didn't sound too sure of himself. I'm sure the regulars in this forum could provide a much more intelligent analysis.
Any help?
Thanks.
(some?) T-Mobile MDA's have an rsupgrade as part of ROM, as they perform a phone upgrade as part of a ROM upgrade. Which has really surprised a few people with the 'wrong' phone (900/1800 as opposed to 900/1900) as they then had to struggle to get phone functionality back.
You can try deleting the file, it no longer serves a purpose after the phone is upgraded. But if it won't delete, I would suspect it's in ROM, and in that case it's not bothering you.
Odd
Emboldended by your advice (Peter Poelman) I prepared to delete the rsupgrade file by first backing up through ActiveSync. However, after doing so, the offending file was gone. Stranger yet, I don't think I reclaimed any memory as a result... (hadn't recorded "before" amount yet - was going to do that after backup. But I think I would notice a 4M difference)
Well, either way, that's one down... Could you (or someone) comment on the MsgQueue* files? They all seem to be SMS related. How MicroSoft could justify allocating nearly *half* of the unit's available ram for some SMS caches is beyond me... Well, for M$ I guess it's not surprising, given the alleged unholy alliance between M$ and the RAM industry.
these files are actually in ROM, not RAM but it's impossible for the end user to know that from the properties of the file. Likewise, according to microsoft, those files are not reporting what is actually being used, it may say 1.7megs but it's not really. Per MS, do not try to delete these files as doing so would render the device broken. I think they have to do with the messaging portion of the PPCPE.
Thanks
Useful info, thanks.
===============================================
I used to use this program to gain space in Nokia :
"Stacker" is the best, fully automatized and reliable compression system for your device. Stacker software doubles the size of your entire drives and works invisible behind the scene. When you start any compressed application it becomes decompressed in background automatically and it becomes compressed again when you close it.
"Stacker" is the best way to increase disks space on your device, it guarantees to give you as much disk space as possible without you even thinking about it!
===============================================
Is there a software that could do the same job of stacker in the XDA?
All files in RAM are automatically compressed by OS itself. You may check that yourself for example by placing a big text document to the root directory on the device and checking the free space change.
There are several programs that compress data on storage cards. For example http://www.pocketgear.com/ppcw/software_detail.asp?id=14226 (I don't know would it work on XDA or not)
Mamaich,
I wanted to thank you for the reply..StackDriver works with any ARM-based Pocket PC device thus it compresses every files in our Storage Card it's a good program but I'm no interested since my Sd is locked while its in the XDA bcz of Sd erasure caused by the WM2003.
pflatlyne said:
Looking back at it,im not so sure anymore. I looked up some information on how the virtual memory in windows mobile works. It seems that whether a program is kept in memory depends on what kind of memory it is stored on. Programs that can be reloaded from flash will be unloaded if needed. Data structures that programs keep,will not be becuase there is no way to restore them.
It might well be possible to swap some of these things out to the transflash card. In fact,vista does something similar with readyboost. Ive actually used my phones card as the readyboost device without problems. What might be a problem is the speed of the card reader in the phone. Some people say the reader is very slow. I dont know if this is true or not,but as a general rule,the card itself is faster than a hard disk,so its not at all unreasonable. One problem of course would be wearing out the flash. Readyboost uses a special algorithm to spread the writes across the drive and reduce the amount of writes. If you just put the swap on flash,it would wear out rather fast.
Click to expand...
Click to collapse
Ive decided that this might not be so crazy as it sounds. This was originally discussed here. http://forum.xda-developers.com/showthread.php?t=350002&page=15
Consider this: http://blogs.msdn.com/ce_base/archive/2006/10/30/What-is-Virtual-Memory.aspx
Now direct your attention to this part from the above link
<QUOTE>
Windows CE will “demand commit” pages, meaning that it will usually delay committing them until the last possible moment. There are also some cases in which Windows CE will take committed pages out of memory again, returning them to “reserved” status:
* Since DLL and EXE code can easily be re-loaded from the file system, it is often decommitted.
* Memory-mapped file pages also have well defined files to read from, so those are decommitted as well.
* Thread stack can shrink; if the system is very low on memory we’ll scavenge the top pages from a stack if the thread is not currently using them.
* Heaps can shrink; if the system is very low on memory we’ll check whether there are heap pages without data in them that can be decommitted.
However that is where Windows CE stops. Other operating systems have a “page file” in which they will write other pages that don’t have corresponding files, notably:
* Stack
* Heap
* Allocations from VirtualAlloc()
* Memory-mapped files that don’t actually have files underneath them (CreateFileMapping with INVALID_HANDLE_VALUE)
* The writable data of executables (global variables)
Those operating systems have algorithms to decide that these pages have not been used in a while, and will write them to the page file and decommit the RAM. Windows CE does not have a page file. We’ll demand-commit to delay committing these pages as long as possible, but once they are committed, the operating system won’t page them out again.
So, as you see, virtual memory in its most minimal definition is just having a mapping between virtual addresses and physical addresses. To lay out allocations in the address space in an efficient manner and avoid wasting physical memory on unallocated address space. In more practical terms, we also use the virtual address space to implement paging, avoid wasting physical memory on allocated addresses that are not actively being used.
</QUOTE>
Here is another interesting article.
http://blogs.msdn.com/ce_base/archive/2008/01/19/Paging-and-the-Windows-CE-Paging-Pool.aspx
Consider:
<Quote>
I’d like to explain a little more about memory management in Windows CE. I already explained a bit about paging in Windows CE when I discussed virtual memory. In short, the OS will delay committing memory as long as possible by only allocating pages on first access (known as demand paging). And when memory is running low, the OS will page data out of memory if it corresponds to a file – a DLL or EXE, or a file-backed memory-mapped file – because the OS can always page the data from the file back into memory later. (Win32 allows you to create “memory-mapped files” which do or do not correspond to files on disk – I call these file-backed and RAM-backed memory-mapped files, respectively.) Windows CE does not use a page file, which means that non file-backed data such as heap and thread stacks is never paged out to disk. So for the discussion of paging in this blog post I’m really talking only about memory that is used by executables and by file-backed memory-mapped files.
</QUOTE>
In short,people are comparing transflash speed to ram speed,realizing there is a vast difference and deciding it wont work. The fact is,the OS is already using virtual memory. It is just not using the transflash and it is not paging certain structures. It still may not be possible,but I think its going to be more of a matter of getting the OS to handle it rather than a speed thing. The quick easy and vastly oversimplified requirements would be to some software on the phone that would create a paging file,manage that file so as not to wear out the flash to fast,and do all the back end work necessary to swap them in and out. What is not clear is how much we can use machinery the OS already has.
Im now going to go into the realm of unsupported speculation. Could we perhaps have a program that manages the paging file(we will call this the page file manager). Its job would be to create a virtual file system inside the page file. Then we could set the pages that are ordinarily not pageable (through some magic algorithm that knows what we REALLY want to not page,and what we can get away with paging to the file) as pageable. I imagine we set them as "file backed" and allocate a virtual file inside the paging file.(our page file manager would manage this for us). The machinery of the OS might then handle all the paging for us. Of course the fact that these structures are writeable would be an issue. Writes to a page would cause an exception and the modified page would be recorded in the virtual file system. Like I said however,this is very early speculation,not even to the level of a plan. In short the idea is to take data structures,make a file for them somewhere,and then make the OS treat them like any other file backed memory page. It sounds almost plausible,doesn't it.
Still more speculatory rambling. I imagine the paging file manager would manage the list of free pages in the page file that are allocated to files and the free ones that can be allocated. It would also manage the order in which they are used,to spread the usage around as much as possible to extend the life of the flash card.
It would go something like this. A data structure is to be paged. A virtual file is created in the paging file,allocated to the size of the data structure to be paged. The structure would be copied to the file and the pages uncommitted. A read to the virtual memory pages would generate a exception and ultimatley cause structure to be reloaded. A write would generate an exception and cause the file to be updated. Page_file_manager would handle this. It would allocate the next available block to the page. It would then update the file allocation table to reflect the replacement of that block in the file and release the original. Of course this all really depends on the internal structure of windows mobile.
Just want a yes or no from an android boffin.
Cheers
Linux does so Android could.
That would be interesting to make the internal and external storage appear as one.
I agree with this idea, but, what popup in my mind is, what happen if one of the disk failed? most high risk is, sdcard damage.
All data or some can be retrieve?
My Galaxy Nexus and Transformer Prime both stop recording at a 2gb file size, is this true of all android devices? Is there any way around it, an app or something? I've tried a couple that didn't work but maybe I missed one that does. I'd like to be able to record at 1080p until the memory card is full. Any help is much appreciated.
I am not exactly sure if this is true for all, but my htc evo 3d is also limited to 2gb.
I've seen conflicting reports, some say 2gb limit, some say they can record until card is full. I'm starting to think nobody can get passed 2gb.
Well in any case you won't be able to record continuously till the SD card is full, because Android uses the fat32 file system for SD card which has a maximum limit of 4GB per file. But 2GB, that's weird, I would think that they at least limit it somewhere near the maximum. Maybe their intention was to keep it at a safe limit to avoid data corruption or something. Plus the Galaxy Nexus has a unified storage (no SD card) which runs the ext4 file system, and that has no small limitation on file size like fat32. So yeah, seems pointless to have a 2GB cap.
Sent from my Desire HD using xda premium
It doesn't make much sense, both the prime and Gnex can save file sizes above 4gb so I dont think they are formatted in fat32. There has got to be a way around it but I haven't been able to search it out.
Yeah, they're not fat32. They're formatted to ext4. I mentioned that previously. Stumps me too why the video size should be limited.
I'm guessing there are some custom ROMs which have this limit increased/removed? Try to search in the development section of GNex forum to find any posts related to this.
Sent from my Desire HD using xda premium
It doesn't make sense, bump one more time to see if anyone knows a way around this.
As sashank said FAT32 normally is limited to 4GB. I read somewhere, that integer which stores size is type unsigned int, so it has range from -2GB to 2GB.
So can galaxy nexus have the FAT32 limit removed on the camera, as it is ext4? Surely, someone has done this.
Did anyone tested video recording on the Nexus 4 ? Does it go over the 2GB limit (on an external EXT card) ?
Has anyone figured out a solution for this? I want to record long videos with the phone fixed at a position. But for me too the size doesn't go above 2gb. I am using a Galaxy Nexus running 4.2.2.
And sorry to bump an old thread.
AbhishekS said:
Has anyone figured out a solution for this? I want to record long videos with the phone fixed at a position. But for me too the size doesn't go above 2gb. I am using a Galaxy Nexus running 4.2.2.
And sorry to bump an old thread.
Click to expand...
Click to collapse
I'm having the same problem. I'm using GS3 i9305 with cm10.1, and the video recording stops at 2GB, full hd 1080p. In stock rom though, the video stopped at 4GB, and showed the message "maximun size reached" or something. I've tried 3rd part apps like Camera JB+ but nothing, it stops at 2GB.
I can transfer files bigger than 4GB to the phone though without any problems (I tried with an 8GB iso file), so I don't know what the problem is. I'm using the internal storage only, no sd card...
also would like a solution for this.
im having the same troubles with my lg thrill 4g.
would be nice to have something automatically split the video file into 2gb chunks as your recording and i could then stitch them together later..
(and no restarting the camera after it auto stops recording wont work as you miss several seconds of whatever it is you are filming )
finally found this thread full of posts from people facing the same dilemma and looking for answers. apparently, there isn't a great deal of interest in the scene for overcoming this limit, judging by the limited amount of threads and discussion on this issue and the fact that there isn't some customisations, mods, roms etc that include element that allow the video recording limit to be exceeded.
it is telling in a way, that the majority of smartphone users never bother or care enough for the issues to be raised and discussed more extensively in the community.
same oroech
hi,
i am still looking for solution the buildin camera apk, but if you are interested in third party apk then visit my thread
http://forum.xda-developers.com/showthread.php?t=2485063
all apk can record unlimited size and duration so it is the camerabuild in restricted from recording over limit and it is nothing to do with fat 32 format, because if it is why other 3rd party apk will work with no issue but i prefer the build in cam apk that is why i like to see solution for that and that is only possible by programmer to decompile . modify and recompile it again, i tired to decompile myself to see if i can get my head around, but i get error when decompiling it while i can decompile some other apk with no problem.
thank you
i think, it's the way how the apps create the file. The Camera app is recording in it's virtual memory backend. And as you know, a 32bit proccess can't allocate more than 2gb ram. I tested several dashcam software and they all crashed while reaching 2GB of recording data. Those apps let you choose to save the record to chunks of x minutes.
just my thought.... maybe i'm completly wrong
TrusterX said:
i think, it's the way how the apps create the file. The Camera app is recording in it's virtual memory backend. And as you know, a 32bit proccess can't allocate more than 2gb ram. I tested several dashcam software and they all crashed while reaching 2GB of recording data. Those apps let you choose to save the record to chunks of x minutes.
just my thought.... maybe i'm completly wrong
Click to expand...
Click to collapse
Probably this particular issue is not technical, although next to that there would be the 4GB limit on FAT32.
It seems that this is an Android limitation imposed due to legal reasons or financial ones, depending how you look at it.
There are several articles on this issue but not just Android, it covers all digital cameras, they have a 30min. recording cap which usually falls on the 2GB limit for most standard Android devices. This is due to a taxation on video recording devices which I'm guessing have one class for less than 30min. continuous recording time and a different class for greater than 30 min. continuous recording time.
According to a few articles I've read, the Word Trade Organization has specified these parameters in their Information Technology Agreement.
Google must have capped this to prevent a bigger taxation on the devices than it already is. I'm guessing the average person doesn't need more than 30 min. of continuous video but even if they do they just have to press 'recording' again. Of course that doesn't change the fact that this thread exists because some people really want the continuous and automated recording to go beyond 30 minutes. I wonder if some Android guru is able to find anything on Android kernel where this is set up as a limitation. Would be awesome to defeat the WTO with one line of code.