I’m running iPadOS 15.4, and Scrivener 1.2.1 (2096)
Copying the project to my MacBook and opening it in Scrivener shows my typing updates from when I was editing on my iPad. Saving the project in Scrivener on my MacBook correctly updates the time stamp on the project file.
This looks like a bug in the iPadOS (iOS?) version of Scrivener.
With what app, where, and which file and folder are you looking to see the iOS time stamps?
Screen shots before change, and after change in Scrivener would be useful.
@rms: With what app, where, and which file and folder are you looking to see the iOS time stamps?
You can see modification dates in Files.app by long tapping on something and using “Get Info”. It is maybe also be the date shown in the list view itself, but who knows, Apple hasn’t felt the need to label that column with any more specificity than “Date”.
To return to the query: I would imagine this is just down to differences in how iOS and macOS handle package formats.
On the Mac, edits made to the contents of a package (which, as you may know, is in reality just a folder that is being treated specially) are considered modifications to the whole. iOS on the other hand is a different beast—package formats are supported of course, you’ll see .scriv folders being treated as files in the Files.app tool, but overall it has a weaker concept of them.
At any rate, neither version of our software has anything to do with so detailed an interaction with the file system. It requests the system update these files here or there, and it does so, and the system handles the consequences and particulars of doing that. It is thus more, if anything, a “bug” in iOS itself—but I’m not sure if I’d even qualify it as a bug. More just like different implementations on different operating systems doing different things. Windows, for example, doesn’t update the modification date on the “.scriv” folder because files within that folder were changed. It will go on showing the date and time of creation for all of eternity unless you modify the very folder itself.
That’s where I was headed…
On my iPadOS 15.4, and Scrivener 1.2.1 (2096), to see this formyself before asking I
So, before going further, seems the OP looking elsewhere, with a different method, or OP’s iPad is different. Maybe just restart it or something. Dunno.
Yes, I would have expected that Scrivener doesn’t do anything to mess with those system time stamps so the “bug” report from @Write4TheFuture is mysterious.
Interesting! For me Files.app shows the creation date in its column view (I think), and the modification date matches the creation date no matter how I try to edit it. I suspect I’m seeing the same thing as the OP in that case, but I have no idea why there would be a difference between your setup and mine. I do need to run an update, evidently (iOS 15.3.1), so maybe that’s worth checking.
Oops. I was wrong. I’m using iOS 15.3.1 (not 15.4 as the OP reported and I just assumed that what’s I had as OP said current. My bad. “Software Update” on my iPad said 15.4 is available, but I’ve not yet tried it. I didn’t know that either. Probably the bug lies in that iOS update but I don’t know. I’ll wait a bit to update, I guess. Only thing that might be affected is sync?
Except I’m also running 15.3.1, so it is evidently not iOS version related.
Only thing that might be affected is sync?
Scrivener doesn’t consider the “project name.scriv” container folder to be of any consequence in determining when to sync. Remember what I said about Windows never changing this folder? If it depended upon that information for when to sync, it would never work with Windows.
Here’s the fundamental conflict I see between the operating system and what Scrivener is displaying. This makes if very difficult to determine what project set is the most recent when copying the project to my backup folders in iCloud and on my other devices. Attached is a screenshot of the File’s app viewing the Scrivener App’s directory alongside the Scrivener app’s editor view of the same. Notice the time-stamp differences. The file app view still shows my previous time-stamp before I made editing changes…
Yes, I understand what you are reporting, but to reiterate, it’s not something Scrivener is doing directly.
By the way, you might find transferring .zip copies to be better all around. If you tap on the Edit button in the project screen, select the project to send, and tap the Share button, you can then file it off to your iCloud folder. As you do so, you’ll note these are date and time stamped, and they will also transfer a lot faster than sending all of the many individual files one by one of the net.
You can achieve the same result on the Mac/PC side by using File ▸ Back Up ▸ Back Up To... in the open project, and selecting your iCloud folder. This again by default date stamps the name.
This is how I’ve always copied things around, and I like how over time you accumulate a stack of previous versions in the folder you use to transfer copies. It’s a little bit of an extra safety net you don’t get if you’re always overwriting the working copy.
Right. But what I’m getting at is iPadOS-Scrivener isn’t updating the time stamp on the actual project folder/file.
(PS: I never use Dropbox because I don’t trust it’s security.)
I WILL use the share zip mechanism in the meantime.
Not something that Scrivener is doing directly? Yeah, I think that was my point. Scrivener is failing to update the time stamp on the project folder/file that it stores in the directory. This is an abnormal behavior if ANY app did this.
I think Ioa’s point is that neither Scrivener nor any other app directly updates the file system metadata. The app sends the “save” command to the file system, and then it’s the file system’s job to save the file and update the metadata.
Actually, in any file system I’m aware of, it would never be something you’d do programatically, to force an update to an enclosing folder whenyou update content within it.
This is always handled by the operating system.
You’ve gotten very good answers above, so it will be helpful to carefully read and understand them, seems from here anyway…
I think the problem is in Scrivener’s packaging mechanism.
Consider this, then: The version of Scrivener for MacOS NEVER FAILS to update the enclosing folder for a Scrivener project. Never fails.
So the replies above are, by the evidence, defective.
The share out of a zipped project file IS a legitimate and effective workaround, and I’ve started using that in the interim. Thanks for showing me the mechanism.
But the iOS/iPadOS version DOES need to be consistent in behavior with the MacOS version (not knowing how the Windows version behaves) — and consistent with the general App policy of updating the timestamp on ANY data object (regardless of format) when modifications are made to it, or its contents.
As a retired software engineer, I can certify that this is expected behavior by anyone using any product.
Fixed it for you.
Again, on any platform, updating the file metadata is the responsibility of the operating system. If Mac OS updates and iOS doesn’t, that’s an inconsistency for Apple to resolve.
Scrivener’s “package” consists of a folder + contents that Mac OS/iOS displays as a single object. The actual structure is exactly the same on all platforms.
I suspected as much. So it’s clear then, that Scrivener is acting inconsistently between the MacOS and iOS/iPadOS versions.
The coding remedy is simple… Have the iOS/iPadOS version ‘touch’ the container when it saves the project.
(MacOS might be defaulting to update folders if any contents are changed while iOS/iPadOS might not.)
I don’t know who’s responsibility it is to make this consistent, but looking at THE LIKELYHOOD of Apple making iOS/iPadOS change their system versus Scrivener? I think it’s far more likely that Scrivener’s modification would appear first. There might be hundreds of App developers out there for iOS/iPadOS that might actually be DEPENDANT on the inconsistency between MacOS and iOS/iPadOS. (Can’t imagine why,) but Scrivener can at least make their own use of the system behave consistently between their versions for different operating systems. IMHO.
