1. What is the problem?
The implementation of FUSE by Google runs using the root-account. The disadvantage is that the standard user is not capable of changing any attribute including timestamp. A copy or move file operation usually keeps all attributes including date and time on all known operating system - except Android if FUSE is involved. This can complicate management of backups or syncing - and sorting or filtering by date is not helpful anymore.
2. What is concerned?
The problem exists at least on all file systems which are emulated by Android using FUSE. Android 8 and later uses SDCardFS and therefore is not concerned.
Concerned from Android 4.0: ext4, exFAT
Not Concerned on 4.0: FAT32
It seems FAT32 is done via FUSE in later Android versions also, so it seems every file system is concerned from 4.1 to last Android 7.
Most Android 4.x-devices are using ext4 for the file system of the internal storage and are therefore concerned. The usage of FAT32 which can not manage file greater than 4 GiB seems not appropriate anyway. For memory cards smaller than 64 GiB it is usual to use FAT32, bigger cards use exFAT by default.
It is possible to access external file systems, eg SAMBA or FTP, and then usually the timestamp is set correctly, because this is not part of FUSE and uses other file systems. AFAIK most file manager still try to set the timestamps, although it always fails without root, and ignore the error returned by FUSE, so copying and moving should be fine. At least Total Commander copies the timestamp fine if writing to Samba using the appropriate plug-in on non-rooted devices.
3. How to recognize/test the problem?
If you copy or move a file, the date and time should be kept. But if the destination on Android uses FUSE, instead of the original timestamp the current date/time is being set. Also all other attributes which the file system may manage (rights, owner, groups etc.) usually are concerned. The original values vanish.
If you want to see which file system is being used for internal memory or some external card you may use the app DiskInfo.
If it shows vfat, it means FAT32.
4. Which possibilities exist to correct the behavior?
Google fixed the bug in Android 8 which was known for a long time (start of 2009).
Google issue 34691 with links to related issues
With Android 8 usage of FUSE was removed, the problem was corrected
https://issuetracker.google.com/issues/36930892#comment120
(careful when using command line under Android 8: cp -a seems not always to be working, but touch -r will)
5. Which possibilities exist to circumvent the problem?
5.0. do not use Android for writing to filesystem: If you don't use Android for writing the files, setting the timestamp mostly will be fine. As mentioned in 4. you can use any filesharing server (Samba, ftp etc.). Storing your documents there instead of the local device will relocate the write access to the filesystem of the filesharing server, which usually manages timestamps fine. There also exist possibilities like adopted storage mode, where the SD card gets accessed by Linux and Android only is being used like a card reader.
As the files have the owner root, all possibilities to circumvent using Android need a rooted device. All following solutions shown here won't work for devices which are not rooted.
5.1. Afterwards correcting (not tested): In the app store there exists at least one app File Timestamp which can afterwards set the timestamp.
5.2. Samba Filesharing runs under root account. If some file is accessed via samba server, the time stamp and attributes can be set correctly.
5.3. Make use of a file manager which sets the timestamp using the power of root on a rooted device:
X-Plore sets file time after copying if root mode is enabled.
Ghost Commander is said to work fine (additional requirement: Busybox)
Total Commander 2.04 and newer support changing the time stamp under root account. On Android 5 and newer you need to use link /storage/xxxx-xxxx for external SD, not ///_Name, to make it behave correctly.
SManager by devwom also deals fine with timestamp using root
MiXplorer tries calling touch. The standard touch on some Android versions is faulty implemented, MiXplorer then only succeeds when BusyBox (internal download of MiX) is installed. Try if it works on your device with your current setup, and have a second look if the timezone correctly evaluated.
5.4. Manual call via command line: Who opens a terminal (eg Open Android Terminal) on a rooted device preferrably with BusyBox can execute commands as root.
Example 5.4.
Archive (also possible on Unix/Windows/etc)
cd <Quelle>
tar -cf <Pfad_zu_Archiv>/Archiv.tar *
Extract
cd <Ziel>
su
tar -xf <Pfad_zu_Archiv>/Archiv.tar
Copy
su
cp -a <Quelle> <Ziel>
The command su changes to root user, so that write access to time stamps is possible. It is always possible to read them, so that it is not necessary to su before archive.
Careful when calling touch: The standard implementation (toybox) seems to be faulty, it does not set the given time when called using -d or -t switch.
Careful when using Android 8 (root not required), it seems at least some implementation of cp does not set timestamp on cp -a
The implementation of FUSE by Google runs using the root-account. The disadvantage is that the standard user is not capable of changing any attribute including timestamp. A copy or move file operation usually keeps all attributes including date and time on all known operating system - except Android if FUSE is involved. This can complicate management of backups or syncing - and sorting or filtering by date is not helpful anymore.
2. What is concerned?
The problem exists at least on all file systems which are emulated by Android using FUSE. Android 8 and later uses SDCardFS and therefore is not concerned.
Concerned from Android 4.0: ext4, exFAT
Not Concerned on 4.0: FAT32
It seems FAT32 is done via FUSE in later Android versions also, so it seems every file system is concerned from 4.1 to last Android 7.
Most Android 4.x-devices are using ext4 for the file system of the internal storage and are therefore concerned. The usage of FAT32 which can not manage file greater than 4 GiB seems not appropriate anyway. For memory cards smaller than 64 GiB it is usual to use FAT32, bigger cards use exFAT by default.
It is possible to access external file systems, eg SAMBA or FTP, and then usually the timestamp is set correctly, because this is not part of FUSE and uses other file systems. AFAIK most file manager still try to set the timestamps, although it always fails without root, and ignore the error returned by FUSE, so copying and moving should be fine. At least Total Commander copies the timestamp fine if writing to Samba using the appropriate plug-in on non-rooted devices.
3. How to recognize/test the problem?
If you copy or move a file, the date and time should be kept. But if the destination on Android uses FUSE, instead of the original timestamp the current date/time is being set. Also all other attributes which the file system may manage (rights, owner, groups etc.) usually are concerned. The original values vanish.
If you want to see which file system is being used for internal memory or some external card you may use the app DiskInfo.
If it shows vfat, it means FAT32.
4. Which possibilities exist to correct the behavior?
Google fixed the bug in Android 8 which was known for a long time (start of 2009).
Google issue 34691 with links to related issues
With Android 8 usage of FUSE was removed, the problem was corrected
https://issuetracker.google.com/issues/36930892#comment120
(careful when using command line under Android 8: cp -a seems not always to be working, but touch -r will)
5. Which possibilities exist to circumvent the problem?
5.0. do not use Android for writing to filesystem: If you don't use Android for writing the files, setting the timestamp mostly will be fine. As mentioned in 4. you can use any filesharing server (Samba, ftp etc.). Storing your documents there instead of the local device will relocate the write access to the filesystem of the filesharing server, which usually manages timestamps fine. There also exist possibilities like adopted storage mode, where the SD card gets accessed by Linux and Android only is being used like a card reader.
As the files have the owner root, all possibilities to circumvent using Android need a rooted device. All following solutions shown here won't work for devices which are not rooted.
5.1. Afterwards correcting (not tested): In the app store there exists at least one app File Timestamp which can afterwards set the timestamp.
5.2. Samba Filesharing runs under root account. If some file is accessed via samba server, the time stamp and attributes can be set correctly.
5.3. Make use of a file manager which sets the timestamp using the power of root on a rooted device:
X-Plore sets file time after copying if root mode is enabled.
Ghost Commander is said to work fine (additional requirement: Busybox)
Total Commander 2.04 and newer support changing the time stamp under root account. On Android 5 and newer you need to use link /storage/xxxx-xxxx for external SD, not ///_Name, to make it behave correctly.
SManager by devwom also deals fine with timestamp using root
MiXplorer tries calling touch. The standard touch on some Android versions is faulty implemented, MiXplorer then only succeeds when BusyBox (internal download of MiX) is installed. Try if it works on your device with your current setup, and have a second look if the timezone correctly evaluated.
5.4. Manual call via command line: Who opens a terminal (eg Open Android Terminal) on a rooted device preferrably with BusyBox can execute commands as root.
Example 5.4.
Archive (also possible on Unix/Windows/etc)
cd <Quelle>
tar -cf <Pfad_zu_Archiv>/Archiv.tar *
Extract
cd <Ziel>
su
tar -xf <Pfad_zu_Archiv>/Archiv.tar
Copy
su
cp -a <Quelle> <Ziel>
The command su changes to root user, so that write access to time stamps is possible. It is always possible to read them, so that it is not necessary to su before archive.
Careful when calling touch: The standard implementation (toybox) seems to be faulty, it does not set the given time when called using -d or -t switch.
Careful when using Android 8 (root not required), it seems at least some implementation of cp does not set timestamp on cp -a
Last edited: