WIP: Fix Android bug on FAT32 time resolution and mtime caching #360
Conversation
|
Not the latest logs, but some proof it works. Real FAT32 card: The |
| @@ -47,6 +54,44 @@ public static String getFullDocIdPathFromTreeUri(@Nullable final Uri treeUri, Co | |||
| } | |||
| } | |||
|
|
|||
| public static int getFilesystemTimeResolutionForTreeUri(Uri startUrl) { | |||
There was a problem hiding this comment.
add javadoc comment here, that returned time resolution is in milliseconds
| // /dev/block/vold/public:xxx,xx /mnt/media_rw/XXXX-XXXX sdfat ...,fs=vfat:16,... 0 0 -> 2000 ms | ||
| // /dev/block/vold/public:xxx,xx /mnt/media_rw/XXXX-XXXX sdfat ...,fs=vfat:32,... 0 0 -> 2000 ms | ||
| // /dev/block/vold/public:xxx,xx /mnt/media_rw/XXXX-XXXX sdfat ...,fs=exfat,... 0 0 -> 10 ms | ||
| for (String line; (line = br.readLine()) != null; ) { |
There was a problem hiding this comment.
log "line" as trace, please, that will help if some users report issues with this somewhen in future
| return new SafSshFile(contentResolver, parentDocumentFile, documentFile, absPath, pftpdService, session, this); | ||
| PftpdService pftpdService, | ||
| SafFileSystemView fileSystemView) { | ||
| return new SafSshFile(contentResolver, parentDocumentFile, documentFile, absPath, pftpdService, fileSystemView, session); |
There was a problem hiding this comment.
should not take SafFileSystemView as parameter, but pass "this" instead
| @@ -76,7 +74,7 @@ public SshFile getParentFile() { | |||
| parentPath = "/"; | |||
| } | |||
| logger.trace("[{}] getParentFile() -> {}", name, parentPath); | |||
| return fileSystemView.getFile(parentPath); | |||
| return (SshFile)fileSystemView.getFile(parentPath); | |||
There was a problem hiding this comment.
why is this cast necessary? why was it not before?
| logger.trace("createFile(DocumentFile)"); | ||
| return new SafFtpFile(contentResolver, parentDocumentFile, documentFile, absPath, pftpdService, user); | ||
| return new SafFtpFile(contentResolver, parentDocumentFile, documentFile, absPath, pftpdService, fileSystemView, user); |
There was a problem hiding this comment.
should not take SafFileSystemView as parameter, but pass "this" instead
| logger.trace("createFile(String)"); | ||
| return new SafFtpFile(contentResolver, parentDocumentFile, name, absPath, pftpdService, user); | ||
| return new SafFtpFile(contentResolver, parentDocumentFile, name, absPath, pftpdService, fileSystemView, user); |
There was a problem hiding this comment.
should not take SafFileSystemView as parameter, but pass "this" instead
|
I'm really looking forward to that merge script 😄 |
The Python sync? 😄 It is working, I've added remote management (start/stop, with Automate or HomeAssistant) for Tailscale, pFTPd, Termux/sshd services (the later for inotifywait, to catch the changes on the fly). I need a few hours net to finalize it on to a v0.1 quality level, though with a newborn and a relocation I hardly find time to sleep. 😨 I will work on the tech comments above on next week. |
|
Happy coding between moving boxes and with new born on arm 😄 |
lmagyar
changed the title
Yeah, this description is quite accurate. :) Just a note: Android inaccurate on file mod. times not only on files we have uploaded, but on eg. new pictures. When we download a fresh new picture through plain-old FS from the SD card, it will have an inaccurate timestamp, but a few hours later it will be rounded to 2s (in case of FAT32) and my sync script will download it again. Not a big issue, doesn't happen too often, but an issue, especially when I delete the downloaded file, and the delete and "modification" causes a conflict. So this solution should be extended to RoSaf and plain-old FS (when we access files under /fs/storage/XXXX-XXXX). Not a big problem, but it needs some time. |
lmagyar
force-pushed
the
pr-fix-time-resolution
branch
from
c126869
to
1b18ecc
Compare
As I wrote in #351 (comment), Android lies about the lastModifiedTime. Even the specs says, that if the time resolution is lower than what we ask, the next getLastModifiedTime will give back the "truncated" value, this is simply not true (tested on real phone, Android 9.0 and emulator). It gives back the truncated values only when he wants, usually hours later. This is an unpredictable nightmare.
This fix:
StorageManagerUtilclass that detects SAF filesystems from/proc/mounts, it detects:fileSystemViewproperty fromSafSshFileup toSafFile, so all SAF file can call the newgetTimeResolution()fromSafFileSystemViewMaybe the default 1ms is overkill, in theory FTP has sub-second resolution, though we can modify StorageManagerUtil to return only 1000 vs 2000 ms, in this case no overload needed in
SafSshFileSystemViewto limit sub second resolution to the 1s resolution of sftp messages.