I understand what this directory contains - It's a directory Mac OS X creates when it does a file system check and places any orphaned or corrupted files it finds in it - and I know why it is created - poor SD card unmounting on the mac - BUT the question I cannot find an answer to... how do you expand the unix file within it and get the lost data (images, photos, music, etc) back?
What's the point of creating this directory & files if nothing can actually access it or expand the orphaned files in the unix files and grab the content from within them and salvage it?
somehow while in Thailand, I lost a bunch of images and this LOST.DIR grew in content/size & has date stamps around that time and now has about 7-8 of these numbered Unix files. I transferred them to my phone but I want to access the contents.
Many people, including myself, enjoyed using the stock Memo application on Froyo and GB. Unfortunately, it relies on TouchWiz so it is pretty unlikely that it will ever be ported to ICS. There are a plethora of note-taking apps out there to replace it, but how do you get your data back?
You don't need a running version of Memo to do this, just a backup of your Memo.db database.
I've attached a couple of shell scripts that you can run either on your phone or `nix / Mac to help you out. Here is the plan:
extract-memos.sh will take the memo data in a copy of your Memo.db, add a new table with columns for human-readable modified and created dates, as well as color, and write out the result (all memos) in a CSV file. You should be able to read the CSV file in most spreadsheet programs and save the data or transform it as you might need for another use.
Code:
[email protected]:~/Documents/memo-export$ sh extract-memos.sh
Checking database: /sdcard/memo-extract/com.sec.android.app.memo/databases/Memo.db
Checking output directory: /sdcard/memo-extract
You may want to see if there is anything important in
/sdcard/memo-extract/com.sec.android.app.memo/shared_prefs/memo_shared_pref.xml
Data exported to
/sdcard/memo-extract/memo_20120714-100915.txt
Code:
[email protected]:~/Documents/memo-export$ cat /sdcard/memo-extract/memo_20120714-100915.txt
_id,title,content,color,modify_t,create_t,color_text,modify_datetime,create_datetime
1,20120712,"A yellow memo",1,1342138985041,1342138985041,Yellow,"2012-07-12 17:23:05","2012-07-12 17:23:05"
2,20120712,"A tan memo",2,1342139010315,1342139010315,Tan,"2012-07-12 17:23:30","2012-07-12 17:23:30"
3,20120712,"A green memo",3,1342139028326,1342139028326,Green,"2012-07-12 17:23:48","2012-07-12 17:23:48"
4,20120712,"A blue memo",4,1342139045894,1342139045894,Blue,"2012-07-12 17:24:05","2012-07-12 17:24:05"
5,20120712,"A pale blue memo",5,1342139064381,1342139064381,BlueGray,"2012-07-12 17:24:24","2012-07-12 17:24:24"
extract-memos.sh expects to find the database in /sdcard/memo-extract/com.sec.android.app.memo/databases
and will write the output in /sdcard/memo-extract
If you already have a copy of Memo.db (I suggest a copy, as the script adds a new table to the database), you can adjust the input and output directories using the environment variables dbdir and outdir.
If you're not command-line savvy, you might want to try creating a copy of Memo.db using extract-files.sh first. It will try, in order:
The GB location -- /data/data/com.sec.android.app.memo
ClockworkMod backups -- /sdcard/clockworkmod/backups
TitaniumBackup backups (default location only) -- /sdcard/TitaniumBackup
and, if successful, copy/extract into /sdcard/memo-extract
You likely need busybox on your phone to run these scripts on the phone. You will need root if you intend to copy from /data/data
To run them on the phone:
Copy the scripts to your phone; here I am assuming you saved them to /sdcard/
Get a shell started on the phone (adb shell, or a terminal emulator on the phone)
Change directory to where you have the scripts
# cd /sdcard/
Uncompress the files, if you haven't already
# gunzip extract-files.sh.gz
# gunzip extract-memos.sh.gz
Get a copy of Memo.db, either using your own approach, or
# sh extract-files.sh
Assuming that succeed, extract the memos into a CSV file
# sh extract-memos.sh
Thanks to m4xm4n for pushing me to make this available. If you find it helpful, please take the time to poke both our Thanks buttons.
If you have problems, please PM me and I'll try to resolve them.
Latest version is 2012-07-14
What is the warning about memo_shared_pref.xml? I don't even have the file!
I had some reasonably useless information about "check" this and that in my com.sec.android.app.memo/shared_prefs/memo_shared_pref.xml My instance of that file dates back to the first release of the phone. I didn't see it on a fresh GB-created version, so it might be Froyo cruft, or who knows. You probably should check this file to see if there is anything useful to you in it.
My _id values aren't all there
Missing _id values are from the memos you have deleted.
What are _id values?
They are an internal number that the Memo app used to keep track of your memos. You probably don't need them to import.
What are the long numbers for modify_t and create_t?
Internal "unixtime" in milliseconds. If that sounded like gibberish, use the human-readable versions that are in your local timezone.
The create/modify times seem off by several hours
Strangely, I have some memos that seem around eight hours off in the opposite way I would expect if they were in UTC. I don't know why.
(reserved for information on importing into other apps)
There are a ton of note-taking apps out there. Right now, I haven't found any that can import the content, the created and modified dates both, and hopefully the color in a reasonable way. If I do, I'll post here how to get the data easily into that app.
Would you be able to post a new link to extract-memos.sh? I just tried clicking on the current one, and both only led to a page that said "410 Gone."
I am running CyanogenMod (CM) 12 on my 1st generation Moto G. In the root directory as shown via the file manager, I created a "notes" folder, where I store text files. Files that I copy over from Windows 7 seem fine.
As an *aside*, the only proviso is that the native CM text editor uses Unix line endings (LF only, not CR+LF). So if the text files were DOS to begin with, any new lines of text added on the handset will have only LF, while old lines will have CR+LF. The CM text editor handles this well, seemingly treating both line endings in the same way.
I have a problem with any *new* text files created on the handset. I am not sure whether the problem is somehow related to the line endings. On the handset, I created a file tmp.txt of length 160 bytes (it contains 160 characters). When I view the text file from Windows 7 using the MTP interface, windows explorer shows the file as having 0 bytes. When I drag the file over to a Windows folder on the laptop, it is basically an empty file. Very bad.
I can use adb to pull the file over, and then it's fine (it's not empty). As a side note, the source path as seen in the handset file manager must be prefixed with storage/emulated/legacy/ when using adb pull.
I do not want to use adb pull to copy over a whole bunch of files. The klag in that process would make it a real headache. I will be regularly mirroring these text files between the laptop and the handset.
Can anyone suggest a reason why a file created on the handset looks so bizzarely empty when viewed over the MTP USB interface? Can anyone suggest a hopefully elegant workaround that doesn't involve too much geeking out? Geeking out is all fun and that, but the handset was really meant to save me time rather than become a project in itself.
Thanks.
It looks like I can avoid individually pulling and pushing files because adb push/pull are recursive commands. The source argument can be a list of multiple files. I might have found from google that a destination directory on the handset must be specified in terms of ./relative/path or might have needed a terminating "/" -- I can't remember, and unfortunately, I closed down my bash shell, so I can't examine the history.
Requirements:
•Root
•Busybox (to use the chattr command)
How to change Instagram Profile Pictures:
1) Wipe Instagram cache
2) Load Instagram
3) Go to /data/data/com.instagram.android/cache/images
4) Rename .clean to .jpg and replace with preferred images
5) Rename back to .clean
6) Open terminal and type 'chattr +i' /data/data/com.instagram.android/cache/images/{files.clean}' {files.clean} being the files that you replaced but without the brackets
7) Next type 'chattr +a /data/data/com.instagram.android/cache/images/journal'
8) Repeat step seven two more times, replacing 'journal' with 'imagev3' the second time and 'journal.tmp' the third time.
9) Exit Instagram from the recents screen and then open it again
Explanation:
Instagram stores profile pictures (and most other pictures for that matter) in its cache folder. This means that these pictures are wiped regularly and the space is then used to store newer photos. This poses a problem if you want to change a picture as it will be deleted and replaced. To get around this, we used the 'chattr +i' command to make the files immutable (can't be deleted or overwritten until you remove the immutable attribute using 'chattr -i').
Now we get to our second problem. The files journal, journal.tmp, and imagev3, which tell the app what each picture is (or something along those lines) , are regularly overwritten. To get around this we used the command 'chattr +a' (append mode only), which allows text (or data) to be appended to the previously existing text, but not to overwrite it, thus making it permanent.
Hi,
All days, several empties folders are created in /storage/emulated/0.
All folders are named with dot then numerics (eg ‘.1896745236489’).
Is it possible to know which app create these folders ?
Thanks
My guess it's something like cookies. The dot in front of filename/folder means the files/folders are unvisible to other apps than the one what created these files/folders.
To get the owner of such files/folders you run
Code:
adb devices
adb shell "stat -c '%U' <path_to_your_file>"