Menu
This question I think is technical enough for Stack Overflow, and probably too programming-oriented for Android. I am intrigued as to how files are handled in Android (or Java or Linux, as appropriate), since I did something with my new smartphone and I'd curious to know how it happened.
I was transferring a file from my laptop to my Android phone, via Bluetooth. I saw the new file in the file explorer, assumed it was fully transferred, and so moved it from /sdcard/bluetooth to /sdcard/torrents. After I had done so, I noticed it was in fact still being transferred. To my surprise, it completed successfully, confirmed with a notification icon on the phone, and by a manual MD5 check on both sides. In most systems, the file move would have caused a crash.
What is the reason for this successful transfer? I'm aware that in general, the file path is separate to the file location on the file system (in this case, an SD card). I imagine that the Bluetooth app has opened a handle to the file, and when I did the file move, a table of 'open files' was updated with a new path. Is this feature generally true of any Linux system? Could I do a mv on a file being written and expect the copy - in its new location - to be correct?
284
You have to use the cp command. cp is shorthand for copy. The syntax is simple, too. Use cp followed by the file you want to copy and the destination where you want it moved.
When you move a file inside the same filesystem, the file itself (the inode) isn't moved at all. The only thing that changes are the directory entries in that filesystem. (The system call invoked by mv in this case is rename(2) - check that page for additional information and restrictions.)
When a process opens a file, the filename is passed to the OS to indicate which file is meant, but the file descriptor you get back isn't linked to that name at all (you can't get back a filename from it) – it is linked to the inode.
Since the inode remains unchanged when you rename a file (inside the same filesystem), processes that have it open can happily keep reading from and writing to it – nothing changed for them, their file descriptor is still valid and pointing to the right data.
Same thing if you delete a file. Processes can keep reading and writing from it even if the file is no longer reachable through any directory entry. (This can lead to confusing situations where df reports that your disk is full, but du says you're using much less space that df reports. The blocks assigned to deleted files that are still open won't be released until those processes close their file descriptor.)
If the mv moves the file across filesystems, then the behavior is different since inodes are specific to each filesystem. In that case, mv will actually copy the data over, creating a new inode (and directory entry) on the destination filesystem. When the copy is over, the old file is unlinked, and removed if there are no open filehandles on it, as above.
In your case, if you had crossed a filesystem boundary, you'd have a partial file in the destination. And your upload process happily writing to a deleted file you can't easily access, possibly filling up that filesystem, until the upload finished at which point the inode would get dropped.
Some posts on Unix & Linux that you could find interesting:
116
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
