Related
Dunno if anyone else has picked up on this but it looks like google might have solved the problem of the G1's (and other phones) low ROM and newer android updates.
Question went something like this:
Q: "Why does the Nexus One have limited storage space for Applications?"
A: "We want to protect our apps and developers however we are working on encrypting apps and allowing them to be stored on the SD".
So basically we have A2SD (legit) coming up soon.
Which means 2.0,2.1,2.5,3.0 etc etc should fit fine on the G1 right?
um, not really
The storage limitation they're referring to deals with the 79 MB size of the /data partition on the Dream.
The android system, though, is installed at the /system partition, 70 MB big. Newer releases add new features, for example, in 1.6 the tts (text-to-speech) service was introduces. In higher capacity devices, there's a folder in /system called /tts (5.9 MB big) that holds the voice data for speech synthesis. On the Dream, however, though the feature is there, the voice data has to be downloaded from the market to be usable, and it's stored on your sdcard.
If future android releases can rely on external resources downloaded to sdcard (plugins, libraries, etc), then the life of the device can be extended, but space is running out and there's no way to add new features without removing others.
What they were talking about in the N1 conference was about the other partition, the /data partition, which stores your personal data, e-mails, mms, settings, and programs. I personally believe the sdcard should have initially been used for that purpose, giving more space to /system, and that way a wipe would require nothing but formatting your /sdcard, however, because of copyright protection of apps (which is useless against a root-user anyway) apps are kept internal, spaced robbed from /system, and sdcard used only for user's files.
What they're now trying to do is to (possibly) have apps now be moved to sdcard, but have those apps encrypted so that they can only be read from the particular system. That way the limit of apps you can install is as big as your sdcard.
I still think all phone ssd should be reserved for /system (and maybe a tiny bit 10 MB /data partition) and leave mms, e-mails, and other infos into xmls in the sdcard so that allows you to move from device to device and keep your data with you without having to re-customize.
jubeh said:
um, not really
The storage limitation they're referring to deals with the 79 MB size of the /data partition on the Dream.
The android system, though, is installed at the /system partition, 70 MB big. Newer releases add new features, for example, in 1.6 the tts (text-to-speech) service was introduces. In higher capacity devices, there's a folder in /system called /tts (5.9 MB big) that holds the voice data for speech synthesis. On the Dream, however, though the feature is there, the voice data has to be downloaded from the market to be usable, and it's stored on your sdcard.
If future android releases can rely on external resources downloaded to sdcard (plugins, libraries, etc), then the life of the device can be extended, but space is running out and there's no way to add new features without removing others.
What they were talking about in the N1 conference was about the other partition, the /data partition, which stores your personal data, e-mails, mms, settings, and programs. I personally believe the sdcard should have initially been used for that purpose, giving more space to /system, and that way a wipe would require nothing but formatting your /sdcard, however, because of copyright protection of apps (which is useless against a root-user anyway) apps are kept internal, spaced robbed from /system, and sdcard used only for user's files.
What they're now trying to do is to (possibly) have apps now be moved to sdcard, but have those apps encrypted so that they can only be read from the particular system. That way the limit of apps you can install is as big as your sdcard.
I still think all phone ssd should be reserved for /system (and maybe a tiny bit 10 MB /data partition) and leave mms, e-mails, and other infos into xmls in the sdcard so that allows you to move from device to device and keep your data with you without having to re-customize.
Click to expand...
Click to collapse
In theory your idea of using the sdcard for all userdata sounds great. However, what about the user who wants to have multiple sdcards for media storage beyond 16GB. Right now, I have like 4 8GB sdcards that just sit around collecting dust (full of tv shows formatted for my G1), because I run A2SD and can no longer swap cards.
The proper way is similar to how Symbian UIQ3 (not sure if other OS's used the same model) gives the ability to store on the removable storage. When you install an app it prompts you to install internally or to the media card. If you chose the external storage - that app is written to that card, where that app stores it's data is up to that app. This way, you have the ability to place lesser used apps, or larger apps, on your removable storage device. While maintaining the ability to swap cards and still have a functioning phone.
I for one, am not satisfied with 16GB of storage for my portable media appetite.
The only limitation is against OVER THE AIR UPDATES.
Dream has *TONS* of space.
Only 50% of the space that could be used for system images is actually used!
Actually LESS than 50% since the stock /system image isn't even full.
Whatever doesn't fit in /system can *VERY EASILY* be moved into /cache.
In building a newer system image, there is also no reason why ALL features must be included! Some features can simply be LEFT OUT.
Maps for example. Leave it out of the system image and force it to be installed from market.
Further compile-time optimizations can also be used to make the compiled image smaller than usual.
Can someone explain to me what is inside the vibrant that is used as storage.
People refer to the internal memory card, why, is it an actual memory card or is it simply because apps cannot be stored there.
Why is the app storage space limited to 2gb if the internal memory is 16gb, and if all 16gb resides on the same medium can't it just be symlinked similar to what people do with apps2sd on other phones with no detriment in performance?
Calcvictim said:
Can someone explain to me what is inside the vibrant that is used as storage.
People refer to the internal memory card, why, is it an actual memory card or is it simply because apps cannot be stored there.
Why is the app storage space limited to 2gb if the internal memory is 16gb, and if all 16gb resides on the same medium can't it just be symlinked similar to what people do with apps2sd on other phones with no detriment in performance?
Click to expand...
Click to collapse
There are 2 storage types soldered onto the vibrant. NAND (fast, small) and "flash" (16g, slow).
The nand is split up for various things like booting, firmware (/system), cache, etc. And - to solve lag with their own apps - 128 megs of it is split out for the built-in apps to use. (That is the 'method 1' fix - move all app data to nand, where it is super fast.)
The 16 gigs of flash is much slower than nand, and split into 2 sections:
- /data (mmcblk0p1) is android apps, app storage, settings, etc. (2 gigs of "application space"). This is the standard android-phone onboard storage, and not accessible to the PC.
- /sdcard (mmcblk0p2) is the 14 gig media/misc space. Standard fat filesystem, shown when you plug into the PC. (They basically subverted the standard android sdcard handling for this - solves some problems, but causes others.)
The removable sd is mounted to "/sdcard/sd".
^ awesome post man, care if I stick it in the sticky?
Disconn3ct said:
There are 2 storage types soldered onto the vibrant. NAND (fast, small) and "flash" (16g, slow).
The nand is split up for various things like booting, etc. And - to solve lag with their own apps - 128 megs of it is split out for the built-in apps to use. (That is the 'method 1' fix - move all apps to nand, where it is super fast.)
The flash is much slower than nand, and split into 2 sections:
- /data is android apps, app storage, settings, etc. (2 gigs of "application space"). This is the standard android-phone onboard storage, and not accessible to the PC.
- /sdcard is the large media/misc space. Standard fat filesystem, shown when you plug into the PC. (They basically subverted the standard android sdcard handling for this - solves some problems, but causes others.)
The removable sd is mounted to "/sdcard/sd".
Click to expand...
Click to collapse
so RyanZA's lag fix, which creates a 1gb file system within the 2 gigs....why can't it be mapped outside of the original appspace since everything resides on flash anyway, the speeds should be the same, no?
s15274n said:
^ awesome post man, care if I stick it in the sticky?
Click to expand...
Click to collapse
Sure. (I wanted to doublecheck some info, so it is slightly updated.)
Calcvictim said:
so RyanZA's lag fix, which creates a 1gb file system within the 2 gigs....why can't it be mapped outside of the original appspace since everything resides on flash anyway, the speeds should be the same, no?
Click to expand...
Click to collapse
"mapped outside the original appspace"? Those words all make sense but not in that order
Data (and cache and so forth) all use samsung's proprietary RFS filesystem. (It has been described as "fat with wear levelling, unix perms and journalling".) The loopback mount fix basically bypasses all that and just shows rfs a large monolithic file. You lose reliability (journal) and flash protection (wear levelling, erase optimization) and so forth, but get speeds much closer to the raw flash. (Personally, I'm a fan of not prematurely destroying soldered on storage..)
One of the things to be tried is yaffs/jffs in place of rfs - all the advantages/protections with much better performance..
Disconn3ct said:
"mapped outside the original appspace"? Those words all make sense but not in that order
Click to expand...
Click to collapse
I understand about the RFS, I just don't really understand why the appspace is limited to 2 gigs when there are 16 gigs on the same piece of silicon. Why is it not a matter of partitioning and mounting the other 16 gigs?
Calcvictim said:
I understand about the RFS, I just don't really understand why the appspace is limited to 2 gigs when there are 16 gigs on the same piece of silicon. Why is it not a matter of partitioning and mounting the other 16 gigs?
Click to expand...
Click to collapse
First, it's not "the other 16 gigs". It is 16 gigs total - 2 for apps/data, 14 for media/etc.
How pissed would you be if only kies (and adb) could get to that storage? That's why - 14 of it is presented as vfat, so that it can be exported over usb to the pc. You might be able to adjust the split a little (eg 8/8) using modified pit files and odin, but I wouldn't even count on that..
Certainly you can't share the space - android security guarantees that only the app (well, and root, but..) can read the app's files. Not the pc, not other apps. So you need something vfat hasn't got (owners, permissions) and you need to not export it to the pc where those limits won't be enforced. (Finally, you only get one fs user at a time - if you have it on the pc, you can't have it on the phone. "Please reboot into usb mode" hasn't been OK since the late 90s...)
Disconn3ct said:
First, it's not "the other 16 gigs". It is 16 gigs total - 2 for apps/data, 14 for media/etc.
How pissed would you be if only kies (and adb) could get to that storage? That's why - 14 of it is presented as vfat, so that it can be exported over usb to the pc. You might be able to adjust the split a little (eg 8/8) using modified pit files and odin, but I wouldn't even count on that..
Certainly you can't share the space - android security guarantees that only the app (well, and root, but..) can read the app's files. Not the pc, not other apps. So you need something vfat hasn't got (owners, permissions) and you need to not export it to the pc where those limits won't be enforced. (Finally, you only get one fs user at a time - if you have it on the pc, you can't have it on the phone. "Please reboot into usb mode" hasn't been OK since the late 90s...)
Click to expand...
Click to collapse
Ok, so if someone did modify the PIT file then it would be possible. It's not a hardware limitation, but just the way the firmware is setup.
What speed is the other 14Gb? How does it compare to standard microSD? Class 4 at least?
Calcvictim said:
Ok, so if someone did modify the PIT file then it would be possible. It's not a hardware limitation, but just the way the firmware is setup.
Click to expand...
Click to collapse
Modify the pit, and the bootloader, and (possibly) the rfs partition scheme, and (possibly) the kernel.
People found a pit that changes the layout a little bit and they're getting a higher-than-normal percentage of bricks. (I don't know how high, but look at all the odin threads that warn against using the new pit..) It is doable, but not reliable yet. Did you already fill 2 gigs of app storage? Thats .. kinda nuts.
applebook said:
What speed is the other 14Gb? How does it compare to standard microSD? Class 4 at least?
Click to expand...
Click to collapse
They claim class 6. With rfs, it is ok until you get to multiple requests - then it goes all thrashy instead of threading properly..
If it's around class 6, then I'm satisfied. Since that memory is for storing media, I have little use for anything much faster anyway.
Disconn3ct said:
People found a pit that changes the layout a little bit and they're getting a higher-than-normal percentage of bricks. (I don't know how high, but look at all the odin threads that warn against using the new pit..) It is doable, but not reliable yet. Did you already fill 2 gigs of app storage? Thats .. kinda nuts.
.
Click to expand...
Click to collapse
I didn't fill the 2 gigs but I don't use the phone for media really, it's just apps and games and just wandering since it would be nice to have more storage for those things.
So what is the size difference between the Vibrants with the larger NAND and the smaller NAND?
What difference does this make in the real world?
Why would they put two different size NAND chips?
SamsungVibrant said:
Why would they put two different size NAND chips?
Click to expand...
Click to collapse
Samsung does some weird things sometimes
Disconn3ct said:
"mapped outside the original appspace"? Those words all make sense but not in that order
Data (and cache and so forth) all use samsung's proprietary RFS filesystem. (It has been described as "fat with wear levelling, unix perms and journalling".) The loopback mount fix basically bypasses all that and just shows rfs a large monolithic file. You lose reliability (journal) and flash protection (wear levelling, erase optimization) and so forth, but get speeds much closer to the raw flash. (Personally, I'm a fan of not prematurely destroying soldered on storage..)
One of the things to be tried is yaffs/jffs in place of rfs - all the advantages/protections with much better performance..
Click to expand...
Click to collapse
So are you saying that samsung's filesystem (rfs) causes wear and tear to the flash drive? Do any of the lag fixes that replace the rfs filesystem (ext 2/3/4) cause wear and tear to the drive as well? I am personally not applying a lag fix for this reason, but if samsung's rfs does that already, might as well take the plunge with a lag fix...
I read somewhere that the nexus one uses a filesystem created for flash drives - it started with a y, probably the yaffs that you spoke of?
Sent from my SGH-T959 using XDA App
veol said:
So are you saying that samsung's filesystem (rfs) causes wear and tear to the flash drive? Do any of the lag fixes that replace the rfs filesystem (ext 2/3/4) cause wear and tear to the drive as well? I am personally not applying a lag fix for this reason, but if samsung's rfs does that already, might as well take the plunge with a lag fix...
I read somewhere that the nexus one uses a filesystem created for flash drives - it started with a y, probably the yaffs that you spoke of?
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
I took him to mean that a loopback mount style lagfix, like OCLF, can cause premature deterioration.
Kubernetes said:
I took him to mean that a loopback mount style lagfix, like OCLF, can cause premature deterioration.
Click to expand...
Click to collapse
That all depends on how samsung implemented wear leveling. It would be insanely stupid to do it in a way that would cause premature death of the flash with a loop file system though. Wear leveling is generally done at the block level so that file systems that have to write to fixed locations a lot like fat don't kill that block. As rfs is fat, I think it's unlikely that it will cause issues.
We can't use yaffs2 and friends without replacing the kernel driver for the flash. They don't work on block devices, they require raw flash access. I suspect it will also require a new secondary boot loader. I wouldn't attempt it without a dev phone and jtag access.
ttabbal said:
That all depends on how samsung implemented wear leveling. It would be insanely stupid to do it in a way that would cause premature death of the flash with a loop file system though. Wear leveling is generally done at the block level so that file systems that have to write to fixed locations a lot like fat don't kill that block. As rfs is fat, I think it's unlikely that it will cause issues.
We can't use yaffs2 and friends without replacing the kernel driver for the flash. They don't work on block devices, they require raw flash access. I suspect it will also require a new secondary boot loader. I wouldn't attempt it without a dev phone and jtag access.
Click to expand...
Click to collapse
Ah... sorry for asking a noobish question and being off-topic a little, but if I were to use a lagfix, which one is best (for the flash drive)?
Thanks for the questions and the answers and for laying it out in understandable terms! A good read.
Sent from my SGH-T959 using XDA App
ive been seeing this... I know its a filesystem for linux, which is something similar to NTFS and FAT for windows..
Question is should i be using this? benefits? does it work for all roms?
I thanked you because I've been meaning to ask this question for about a week now. I've noticed several roms here also make use of the Ext4 system and wondered about what type of advantages were offered.
Considering you noted it was a linux file system, I'd imagine there would be some speed increase associated with it but again, I have no clue when it comes to this. If it wasn't for you, I wouldn't even know it was associated with linux.
it isn't really a "you should or shouldn't", it's really just "do you want to?"
but i will say though, most of the ROMs available these days all have EXT4 filesystems, so i guess you don't really have much choice.
so if the rom comes like that, do i still need to do this myself?
or do i need to do the Ext4 on the SD card itself?
gd6noob said:
so if the rom comes like that, do i still need to do this myself?
or do i need to do the Ext4 on the SD card itself?
Click to expand...
Click to collapse
if a ROM comes with an EXT4 filesystem, you shouldn't need to do it manually
Honestly, unless you are making a ROM or like to micro tweak your way into figuring out how stuff works, you shouldn't need to care about what the file system is, as long as it works .
My current phone/tablet use ext4, I think my old phone used yafs2. When you might really want to care is if your phone crashes a lot, you store a lot of data (that isn't also in the cloud), or you want to turn your phone into a Wireless Network Attached Storage (WNAS), in which case you should probably soder in a standard hard drive anyway.
Sent from my Transformer TF101 using Tapatalk
I was considering storing financial and personal information on my phone in the form of files and realized that though the fingerprint scanner is ok to prevent the casual browser from logging into the phone when it is left unaccompanied, a real hacker could easily see whats on there with very little effort.
The Atrix on the face of it looks like a secure phone with the fingerprint reader; however XDA users would know that nothing prevents a thief from entering fastboot and mounting the files and folders to see whats on there. No security app can prevent that.
Using the android built-in option and encrypting the entire sdcard is NOT an option for me at this time. I think its going to slow down the phone operation if the OS files are encrypted and each time it needs to decrypt each and every file and folder. Also it may present issues when testing new ROMs. (And I am dual booting - so my extSD also has a ROM which I would not want to slow down anymore than it already is)
So I searched for methods and apps to encrypt individual files or folders on the Atrix. There are quiet a few in the market and a few are free as well with good reviews. However most -even the ones with the best reviews seem to be just changing the file name and location and not doing real encryption. Also most of these use proprietary algorithms or methods to hide information. A really good app would be one that uses an open source algorithm to encrypt the files and folders - so that the algorithm would be tested and verified as being strong by the world.
Also another requirement was for the ability to frequently sync and update the files on the phone with the PC. The app should have a PC equivalent - that is the file can change on my PC and then I should be able to sync the changed file with the phone in some automated way.
Yet another requirement would be the ability to quickly encrypt and decrypt huge audio or video files. A few good apps could encrypt small audio and video files but not files of size 1GB or more. The apps would either freeze after some time or not encrypt them at all.
Finally I was looking for an option by which the files if I unencrypt them to be available across all apps for the duration of that session - not just in the app that encrypts and decrypts them. So in other words, once I enter the password, the folder should be mounted and available in any app that can browse the phone - until I decide to end or unmount the encrypted store.
I found only Cryptonite doing all of this. Unfortunately Cryptonite does not support Truecrypt containers on Motorola phones. There is some info here on the truecrypt port to android here:
http://forum.xda-developers.com/showthread.php?t=872297&page=7
However I could not get it working with the Atrix. Has anyone had success getting Kryptonite and Truecrypt to work on the Atrix?
Cryptonite also supports Dropbox, but I am not a big fan of storing sensitive info in the cloud - however well known the company is.
Cryptonite does support encFS and I was able to successfully create encFS encrypted folder on my Atrix. I would have liked to have TrueCrypt than encFS, just because I have been reading that Truecrypt has better overall support.
The method I use now for storing and synching encrypted information is:
for the first time only: create the encfs folder on the PC, then mount Atrix as a USB drive and copy the encrypted folder to Atrix.
To sync the encrypted files with the PC, I have to connect the Atrix as USB drive, open EncFS on the PC and select the folder on the Atrix to mount as a drive volume. Also mount the PC encFS folder as another drive. Now sync with the PC using any sync tool like MS SyncToy.
I went through a lot of searching and came to this which I think is good enough at the moment. I would like to hear if anyone else has a better app or method to secure and sync secured files on the Atrix - especially if you have got Truecrypt to somehow work on the Atrix. And I post this so that is anyone else needs this information, it is here.
shenoyh said:
Yet another requirement would be the ability to quickly encrypt and decrypt huge audio or video files. A few good apps could encrypt small audio and video files but not files of size 1GB or more. The apps would either freeze after some time or not encrypt them at all.
Click to expand...
Click to collapse
I don't know about the rest of it, I never used any strong security on my phone nor do I intend to, but I think you shouldn't ever expect to be able to "quickly encrypt and decrypt huge files". You're pretty much asking for impossible here. It's like asking to build a full-featured house, furnished and all, in 30 minutes or less. A lot of data will always require a lot of time to process. Heck, even, say, straight plain copying such a file to a computer would take quite a while.
No.
Your not going to get business class security on your atrix, or any current phone most likely.
LUKS manager is the closest thing to legitimate encryption (not gimicky BS) i have seen, but it has some fatal flaws.
Passwords and such are safe and easy to store with KeePass, which is also on windows/linux for syncing and has years of reputation (also free/open source). It isnt for files though.
-------------------------------------------------
Atrix 4G
Rom: Cyanogenmod 7.2 [20120805]
Recov: Romracer 5.0.2.7-atrix5
Radio: N_01.97.00R
Kernel: Faux 1.00ghz-026b1
UV: -0/-25/-50/-100/-150/-225/-300
Hello, all.
Is it yet possible to access the internal storage of a Lumia 1020 (mass storage mode) under Windows Phone 8.1, in order to recover accidentally deleted data?
Thanks.
Nope.
P.S. Next time please use the appropriate forum for this kind of questions...
sensboston said:
Nope.
P.S. Next time please use the appropriate forum for this kind of questions...
Click to expand...
Click to collapse
Theoretically it is (given someone needs to make the app) and just port over DiskDigger from Windows over to WP using the same methods as the WPTelnet application. I would not be able to do this because I do not know C++ but it is possible technically.
Maybe something worth looking into.
I'd offer some money to the person who can solve this problem. Feel free to contact me directly if you can make it happen. Thx.
WP system is build for security. this not android. if you want your data safe, learn how to backup and use money for other things...
sandix said:
Theoretically it is
Click to expand...
Click to collapse
Not even theoretically 'cause AFAIK WP is using MTP protocol, not a mass storage. And we don't have "interop" unlock for the micro-sd-less handsets now, on WP8/8.1
Mr. Barker said:
I'd offer some money to the person who can solve this problem. Feel free to contact me directly if you can make it happen. Thx.
Click to expand...
Click to collapse
If your information is really important, and you agree to spend a lot of money (it will be a REALLY LOT OF MONEY!) for the procedure, I believe some companies specialized on data recovery are able to help you (sorry, can't provide any links). But AFAIK it will cost thousands, not a hundred bucks.
sensboston said:
Not even theoretically 'cause AFAIK WP is using MTP protocol, not a mass storage. And we don't have "interop" unlock for the micro-sd-less handsets now, on WP8/8.1
Click to expand...
Click to collapse
but we have it for Windows 10 devices .
you have any idea for interop unlocked devices to recover ?
@ngame, I read an article (probably here, in this forum but the article located on the different site) about hacking WP8 with JTAG. The guy who wrote this article, claimed about successful hack of the file system (even encrypted but I can't remember exactly).
So it's my assumptions that companies who specialized on data recovery and security, already has methods and technique to access WP NAND (using specific hardware of course) but I'm unsure, it's just an assumption. We've (my old company) already had an experience with some sort of these guys (we've successfully recovered "died" (actually, died and fried!) HDD), they are awesome!
But this have a sense if you have a really important information stored in the handset only. For example, you've shoot one of the most wanted criminals in US and FBI asked you for the proof to get a reward. However if you wanna get your ex naked pics, will be much cheaper to give her a couple of hundred $$ or ask your best friend to do this - you'll get these pics for free
sensboston said:
Not even theoretically 'cause AFAIK WP is using MTP protocol, not a mass storage. And we don't have "interop" unlock for the micro-sd-less handsets now, on WP8/8.1
Click to expand...
Click to collapse
I was talking more specifically of data recovery on the phone, by using an app built to scan the drive for lost files. so the app would not need MTP to do a scan of the filesystem.
@Sanix, OP mentioned "mass storage mode" which one not exist BTW, how you'll scan the drive by using WinRT API? First of all, your access (on the regular handset) to the file system is strictly limited. Second, I'm pretty unsure that you can use some low-level APIs to access file system with read/write operations on the NTFS clusters/sectors (not sure) etc.
sensboston said:
@Sanix, OP mentioned "mass storage mode" which one not exist BTW, how you'll scan the drive by using WinRT API? First of all, your access (on the regular handset) to the file system is strictly limited. Second, I'm pretty unsure that you can use some low-level APIs to access file system with read/write operations on the NTFS clusters/sectors (not sure) etc.
Click to expand...
Click to collapse
With the ability to run C++ code in a wrapper of an XAP (given that the permissions are proper) a simple port of DiskDigger should do the trick.
I do not believe that Windows Phone runs with NTFS but I could be wrong.
sandix said:
With the ability to run C++ code in a wrapper of an XAP (given that the permissions are proper) a simple port of DiskDigger should do the trick.
I do not believe that Windows Phone runs with NTFS but I could be wrong.
Click to expand...
Click to collapse
WinPhone uses NTFS for System and Data partitions. Other are FAT or raw.
-W_O_L_F- said:
WinPhone uses NTFS for System and Data partitions. Other are FAT or raw.
Click to expand...
Click to collapse
Nice to know. Can open a lot of doors if we can get System applications like dd working. I can see something like dd being a life saver for a lot of people.
By the way, that's all just a blah-blah-blah... For the OP, the answer is the same - "no, you can't"
sensboston said:
By the way, that's all just a blah-blah-blah... For the OP, the answer is the same - "no, you can't"
Click to expand...
Click to collapse
Yeah, that is true, as of now there is no way to recover deleted data without a 3rd party.
Yeah, the raw partitions (and APIs to access them) do exist, but apps don't have anywhere near the privileges necessary to access them. You'd need arbitrary code running as Administrator or LocalSystem. That's without even considering the problem of phone encryption.
That's a real shame that nothing can be done. If they had only included an SD card slot on the 1020, I wouldn't be facing this problem.
A data recovery center would be fine, except the data I need back is confidential & I don't want any strangers feasting their eyes on it.
I suppose I shouldn't hold my breath in regard to this situation with the file system being resolved any time soon, but I'll keep on eye on this forum just in case.
Thanks for the replies.