3

Once upon a time, you could plug an Android phone into a computer running one of the three major OS's (Linux, macOS, Windows), and it would present an interface to the computer that looked like a disk drive (USB-Mass Storage Class) containing a FAT32 filesystem. That made it easy to copy files to or from the phone, edit them in place with any editor running on the computer, or use any other application running on the computer that simply treats the files on the phone as ordinary files. But Google had a better ideas -- NOT! Around 2012 they got rid of that interface and replaced it with MTP (Media Transfer Protocol). That created a whole host of problems, one of which is that when files were copied from the computer to the phone, the timestamp was changed to the current time rather than preserving the timestamp of the source file. People constantly complained about that, but for years Google seemed uninterested in fixing it. Then, around 2017, Google finally fixed it by replacing the FUSE-based filesystem implementation running inside the Android OS (FUSE = Filesystem in User Space) with SDCardFS. There's an excellent explanation of the problem at https://www.xda-developers.com/diving-into-sdcardfs-how-googles-fuse-replacement-will-reduce-io-overhead/. It explains that the architecture of FUSE-based filesystems means that the process that issues the utime() system call to set the timestamp is running with insufficient permission for that system call to succeed.

It now appears that Google didn't sufficiently vet SDCardFS before incorporating it into the Android OS. They're now deprecating SDCardFS and replacing it with "a new FUSE implementation". (See https://source.android.com/docs/core/storage/sdcardfs-deprecate).

I'm concerned that in reverting back to a FUSE-based filesystem, the old timestamp problems will reappear. I'd like to bring this to the attention of one of Google's Android OS developers to find out if they considered this when they decided to revert to FUSE, and if so, whether or not their new implementation allows the preservation of timestamps of files copied to the phone. Does anyone here have any idea how to contact those developers?

MBR
  • 31
  • 3
  • Perhaps you might be interested in https://source.android.com/docs/setup/contribute/report-bugs: "You can help improve Android by reporting issues and feature requests in the Android Issue Tracker. The Android Issue Tracker contains a list of pending technical tasks across a variety of topics, information relevant to those tasks, and information about progress on those tasks, including which ones might get worked on in the short term." Aside from that, I'm not sure if there's any way to contact the developers directly. – Andrew T. Jan 21 '23 at 08:37
  • @MBR Did they change the default FS used on SD cards, the FS driver(FUSE), or the USB transfer protocol? What exactly are you asking? – svin83 Jan 21 '23 at 10:17
  • @MBR and which timestamp are you referring to when you say The Timestamp? Most files on most file systems have atleast two timestamps, some filesystems support 3 or even 4 timestamps, but no FS supports every timestamp available. – svin83 Jan 21 '23 at 10:21
  • actually we are not talking about (fat) MicroSD cards but (f2fs) Internal Storage (and he meant mtime) – alecxs Jan 21 '23 at 19:22
  • That said, while this question can be useful to the community, I'm afraid as of current writing the title is unclear about what is the "longstanding bug" (I guess it's "the timestamp still preserved after reverting back to the FUSE-based filesystem"?). Could you [edit] and improve it? – Andrew T. Jan 22 '23 at 02:51
  • Andrew T.: Thanks for that link. I'll try posting there. – MBR Jan 22 '23 at 06:14
  • svin83 - Around 2012 they replaced MSC/FAT32 with MTP. But the MTP implementation was built on top of FUSE, which caused a permissions problem resulting in the modification timestamps of files copied from the computer to the Android to be wrongly set to the time the copy was done rather than the timestamp of the source file. In 2017, they fixed that problem by replacing the FUSE implementation of MTP with one based on SDcardFS. In 2020 they dropped SDcardFS in favor of an MTP implementation built on a later version of FUSE. I'm hoping that didn't bring the timestamp bug back. – MBR Jan 22 '23 at 07:11
  • svin83 - This is in a separate comment because including it in my previous response would have put me over Stack Exchange's character limit.

    At this point, this no longer has anything to do with actual SD Cards, since modern Android hardware no longer has an SD card slot. But for historical reasons, some things like SDcardFS and the filesystem mountpoint still mention the SD card in their name, even though it's no longer there.

     – MBR Jan 22 '23 at 07:21
  • @svin83 Ever since I first started writing Unix code back in 1980, "the timestamp" has always been shorthand for mtime (time of most recent modification). That's the one displayed by ls -l. Although the ls manpage mentions "ctime" and "atime", it doesn't bother to mention "mtime". It's just assumed. – MBR Jan 22 '23 at 07:44
  • @Andrew T. - I edited the title to more explicitly describe the bug. I hope that's better. – MBR Jan 22 '23 at 07:55

0 Answers0