Fix setLastModified() exception on SAF

[lmagyar]

In theory it is not possible: DocumentsContract.Document.COLUMN_LAST_MODIFIED is read-only.

In reality it is possible: we can't write the SD card's files with the file API, but we can set the attributes with the file API (what we can't through SAF, "great" design).

The solution is a copy-paste from https://stackoverflow.com/questions/63495498/android-scoped-storage-getcontentresolver-update-column-last-modified/66681306#66681306

Note: I also removed the sshFile.setLastModified(new Date().getTime()); call in each SSH_FXP_WRITE

• setting the current time is the responsibility of the OS
• yes, it is in v0.14.0 mina/sshd/sftp, but as I see in the latest, it is removed there also https://github.com/apache/mina-sshd/blob/master/sshd-sftp/src/main/java/org/apache/sshd/sftp/server/SftpSubsystem.java#L879

fixes #145

Tested on Android 9.0, Samsung A8

[wolpi]

Is it necessary to remove that?
When/where is setLastModified() invoked?

[lmagyar]

It's not necessary strictly, but slows down the copy, it calls this after each write block. Depending on the client (block size 4k-64k), 100 or 1000 times during each a file upload. :(

When invoked? In case of WinSCP:

• If I turn off "preserve timestamp", WinSCP calls only open/write/close, and the OS sets the last modified time.
• If I enable "preserve timestamp", it send a separate SSH_FXP_SETSTAT message, and that sets the timestamp.
• Tested with SAF and POFS (plain old FS) and reading the ftpd logs.

[lmagyar]

FYI: And now I've tested it with even directories, this works even on them!

[wolpi]

Ok, that sounds all good

[wolpi]

Many Thanks

[catscarlet]

OMG.
6 years.

[lmagyar]

OMG. 6 years.

:) All credit goes to https://stackoverflow.com/users/15401262/usilo

[lmagyar]

One strange issue, seems to be an Android bug:

• using FAT32 (32GB external SD card), with 2 second modification time resolution
• setting a time to eg. 23.55 seconds with SETSTAT, SFTP protcoll will truncate it to integer seconds, ie. 23.00 seconds
• reading back the modification timestamp with STAT gives 23.00 seconds, hmmm, strange, even when updating it through SAF and reading back from plain old FS, or vice-versa (OK, same file, but seems to be a low level Android cache issue)
• nondeterministic way to emtpy some Android cache: restart pftpd, but sometimes it's not enough, we have to wait or completely restart the phone
• reading back the modification timestamp with STAT gives 22.00 seconds, truncated to even integer (SAF and plain old FS also)

So it seems Android caches this mtime info, though the backing FAT32 FS stores only even-integer truncated values. When the cache is deleted and values are read from the real FS, timestamp magically changes...

This made me mad, I'm trying to create a bidirectional sync script, and even if I read back the "real" timestamp with STAT after SETSTAT, files started to change "randomly" during the night. They got 1 second older. Only the ones, that were odd-something seconds old on the previous day...

Android, what a mess...

Now I'm investigating where to put the workaround, in the ftpd server or in the sync script, I have to find a way to determine the filesystem's mtime resolution.