===============================================
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.
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.
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?
Hey !
I've searched the web as well as the forum but i didn't find any solution and it seems i'm not the only one wanting to do that.
Is it possible to see hidden folders of internal sdcard through MTP ?
I really talk about hidden folder like ".android_secure", not the photos that aren't yet scanned by the media scanner service.
In my windows environment i already set the view all hidden files/folders as well as view system files.
If i have to change folders permissions through terminal what are the correct permissions i should put ?
Thanks for the help !!
Am i the only having that problem ?
Do you guys see the hidden folders through mtp connexion ?
If you'd bother reading a bit before asking questions, you might have the answer already.
http://en.wikipedia.org/wiki/Media_Transfer_Protocol
MTP and PTP specifically overcome this issue by making the unit of managed storage a local file rather than an entire (possibly very large) unit of mass storage at the block level. In this way, MTP works like a transactional file system - either the entire file is written/read or nothing.
More or less, it is designed to keep hidden what should be hidden stick to USB storage or FTP/SCP.
PS: can't believe we're using a transfer protocol designed by Microsoft in a Linux-based system mastered by Google. The horror, the pain... no wonder it doesn't work on my Mac!
VAXXi said:
If you'd bother reading a bit before asking questions, you might have the answer already.
http://en.wikipedia.org/wiki/Media_Transfer_Protocol
MTP and PTP specifically overcome this issue by making the unit of managed storage a local file rather than an entire (possibly very large) unit of mass storage at the block level. In this way, MTP works like a transactional file system - either the entire file is written/read or nothing.
More or less, it is designed to keep hidden what should be hidden stick to USB storage or FTP/SCP.
PS: can't believe we're using a transfer protocol designed by Microsoft in a Linux-based system mastered by Google. The horror, the pain... no wonder it doesn't work on my Mac!
Click to expand...
Click to collapse
Thx for the link ! I knew what mtp is but its always good to refresh things up
I read the whole article and unfortunately it doesn't answer my question.
I understood that its the same for all of us meaning that we are not able to see hidden folders.
But the main question is if there is a way to bypass this behavior ? Where is this defined exactly ?
It seems according to the article that its not on the file permission layer ? Should it be at partition level ? How can mtp know what to share with the host ?
It's not a "behaviour" per se, but more/less a database. Remember that media scanner program which wakes up every time you change something on your SD card, be it internal or external ? it simply keeps a "database" of files which are presented to the MTP client (your computer) and hides away the phone's internal folders which are not supposed to be seen by the end-user.
Theoretically, this is done in order to have the iPhone-like behaviour: seeing the entire device memory as one big unified storage which you can fill as you want (no more of those partition size limitations which brought us the app2sd hacks). In my opinion, it's more or less just a small step done in order to "secure" phones for DRM protected content.
Studios and media companies require devices to have such measures of protection in order to allow you to sell media content (like movies, books, etc) and since Google wants to push its business further with the Play Store, it needs to cave in to the studios' demands. In the future, it will probably even become illegal (DMCA-style) for me to give you the information below
Back to the technical part of our show now.
At the first boot in the life of the device, Media Scanner will look under /system/media and index everything there. After that, it will scan everything under /mnt/sdcard (hence your external SD card too, if you have one, as it's mounted under /mnt/sdcard/external_sd). On some devices, you have an "internal.db" file and one "external-123xyz.db" file; that's a unique ID of the SD card which was scanned. The idea here is you might have 2-3 SD cards which you swap often, and it's not nice to do a full rescan each time you change the SD card. These databases are in /dbdata/databases/com.android.providers.media (on my phone, there is only one "external.db" for example).
So what you're looking for is a way to populate this database with all the files found by the Media Scanner. But Media Scanner doesn't want you to see the hidden folders you mentioned above. So, you get an application which doesn't ignore them, like Rescan SD Card! or SDrescan.
Happy now ?
Thank you very much i really enjoyed reading the explanation as it answers completely my questions and it makes sense !
Ill give a try to the apps but i'm also curious to investigate on those files
Cheers
PS. Is this a disguised way to support non open source protocols ?
Well, you could poke around inside the database with sqlite if you want. But don't really see what's so interesting about them.
It is just another protocol which is supported, which happens to be designed by Microsoft (and probably licensed/paid by Google to be used in Android). I understand the technical explanation behind this decision, but I'm also wary that someday UMS will be disabled by default and enabling it will disable content purchasing for that device (just like having a rooted phone now disables some "sensitive" apps, like banking and online TV).
As a system admin its interesting to know whats happening on my system
As a hobby its interesting for my personal knowledge
And from a development point of view it gives me some ideas for maybe future apps
You say that its just another protocol which is supported but to my understanding there are not so many of them ! So i would say that Google was kind of forced to use the MTP method, first from a hardware point of view and second to be compliant with the rest of the world.
Is there any other protocol that could suite their needs ? Since USB mass storage is not usable on some devices and MTP is well spead.
.HiddenAndroid folders in Win - Here Yesterday, Gone Tomorrow
<Win 7 and GN2>
What's curious and a bit frustrating to me is that, yesterday, when I mounted my device ALL of the hidden (.folders and .files) were visible and searchable. Today, when I went to explore some more, all are gone. I understand that I can use a 3rd party app, just can't figure out why it was visible yesterday and not today.
Hmmph
Did you ever resolve this issue? I really hate MTP for several reasons but this is one of the reasons why! I need to back up all my directories on the SDCard because some apps store them as hidden files in hidden directories. Furthermore, I came across the Play Store bug that requires me to delete a "temp.asec" file in the ".android_secure" directory, but of course it is not visible.
In a post further up it was suggested to use a "Rescan" app to force the DB to include hidden files/directories, but I have tried no less than 4 of these apps, and all they do is trigger the built-in android media scan, which is the problem in the first place!
So has anyone ever been able to access hidden files and directories using MTP?
EDIT: I have an HTC phone that actually shows hidden files and directories, so they have obviously implemented their own media scan. The problem I am currently having is on a Samsung phone (Epic 4G touch)
It may depend on the implementation. For example, using stock rom for the phone doesn't show some files and folders, for example folders starting with dot. But if you use Neatrom Lite it will show all files and folders.
Flash forward about 6 years and Samsung still does not show hidden folders/files when viewing the phone contents in Windows File Explorer, but HTC does.
The reason this is still a problem for me, is that I want to backup the contents of a particular directory (WhatsApp) which contains some hidden folders, so I can restore it anytime on a new phone or the same phone.
I recently switched from HTC to Samsung and alas, it seems the problem with this implementation still exists. Anyone found a workaround to this to allow File Explorer to see the hidden folders?
Update: It appears that hidden .nomedia files (and probably others) appear under regular folders, so the problem is limited to hidden folders themselves
Hello all, I have received a TON of false positives in my search for whether this is even possible.
In windows, a shortcut to a file or folder can be stored in any folder.
So far in Android, a shortcut can only be placed on the home screen, and AFAIK does not have a corresponding file that can be found in the root browser.
I am trying to trick Handshaker into giving me access to my EXTERNAL SD, and the only way I can think of is to create a shortcut somewhere on the internal SD that zips on over to the card where all my media (100Gb+) is stored.
I'm on a OPX, so internal storage BARELY COVERS apps. No switcheroo action is reasonably doable.
As an aside, is this whole Mac incompatibility thing a vestigial grudge? It must take a lot of effort to KEEP usb from working as it should. Are there other apps besides the "works when it feels like it" Android File Transfer or "installs weird **** on your phone" HandShaker that allow you to move around YOUR OWN FILES without using the cloud? The amount of web silence and lack of development is stunning to me. Maybe I need to refine my search terms?? Unlikely. I've tried many tens of iterations.
The search for answers here results in a mountain of false-positives as well.
Thanks for taking the time to at least read this.
Cheers.