-2

I have a text file (or jpg photo) in android, which is essentially a modified linux system (I have some experience writing native C code in android using NDK). I simply want to find the physical memory address for the start of this file/photo. So get a return value of something like: 0x9abcdef0. My understanding is that files/photos are stored somewhere on physical memory address space, if this assumption is wrong, let me know.

I have looked into calls such as mmap, and couple of SO posts, but they don't really do what I want, which is just return the address. I also don't need functions like open() or file descriptor related stuff, looking to get that lower level real address.

How to access physical addresses from user space in Linux?

linux kernel - how to get physical address (memory management)?

use mmap in C to write into memory.

Bqin1
  • 467
  • 1
  • 9
  • 19
  • It seems highly unlikely to me that the entire filesystem would be accessible in RAM. That's the whole point of having a large storage media versus fast non-permanent storage. What is the _actual_ problem you need to solve? – paddy Aug 08 '19 at 04:30
  • 1
    @Bqin1: In that case you have an XY problem. The way to achieve this is not to "get the physical memory address of the file". Ideally you would just make hard links to the files in a location that the delete UI doesn't know about, so when it deletes the files there's still a link remaining. However, I'm not sure the filesystem photos are stored on allows hardlinks. Alternatively you could watch the directory and just make backups (albeit wasting space) of everything created there. – R.. GitHub STOP HELPING ICE Aug 08 '19 at 05:33
  • @R Thanks, I have already tried the backup, that method wastes too much space. Regarding hardlinks, what do you mean, can you give an example of how to create this hardlink in linux? – Bqin1 Aug 08 '19 at 13:05

1 Answers1

3

My understanding is that files/photos are stored somewhere on physical memory address space, if this assumption is wrong, let me know.

This assumption is wrong.

Files have their permanent storage on "disk" - on a typical Android device, that's going to be eMMC, which is essentially an SD card soldered on the motherboard. Files on disks are stored in filesystems, a collection of data structures that let you get from a pathname to a file and from a file and offset to the location on the physical storage where that offset of the file is located.

Files generally have no permanent existence in physical memory. When being accessed, parts of them will reside temporarily in memory at varying physical addresses. If mmapped as a shared mapping, they will be addressible at a fixed virtual address in the process for the lifetime of the mapping, but the physical memory behind this mapping can vary at any time.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • Hey thanks for the explanation, I understand some of it, but confused by some parts. you say files on physical memory can vary at any time, but then how does system know where to find this file if it keeps hoping around? You also say files have permanent storage on disk, then wouldn't the address of this permanent storage on disk be what I am looking for? Is it a hex memory address format, and can we return it? – Bqin1 Aug 08 '19 at 04:44
  • Yea, I didn't like mmap because I don't need to map virtual addresses. My process will die so the virtual address gets recycled anyways. I need a permanent/lower system level handler to files – Bqin1 Aug 08 '19 at 04:47
  • @Bqin1: There is no permanent handle to files. On flash-based storage (SSDs, SD, eMMC, etc.) the physical location isn't even exposed to the cpu/OS, and it's constantly moved around for wear leveling each time changes are made. There are logical addresses of storage blocks, but the blocks associated with a particular file need not be contiguous, and it's up the the operating system's filesystem implementation whether they remain fixed over time (for example, a good implementation may attempt to move them around to defragment)... – R.. GitHub STOP HELPING ICE Aug 08 '19 at 05:03
  • In any case, the closest thing to a permenant handle for a file is a pathname referring to it. – R.. GitHub STOP HELPING ICE Aug 08 '19 at 05:04