rsync's optimization strategy of only transferring changed files is defeated by all files having their modified timestamps updated to the current time when pdc copies them from the source folder to the pdx. This includes the chunky ones that slows our transfer down, like mp3's and pdv.
Could this be fixed? This could also be used to improve the transfer speed of uploading from the simulator, where the same issue is seen.
@dave sorry to bother, but this one might have flown under the radar.
Even though we are supposed to test on simulator, there is a phase in development where you are going to spend more time on device. Fixing this issue would improve development quality of life massively, I think. In my limited capacity to estimate effort, this would be relatively easy to implement. Eespecially for unmodified files like json and mp3, where the copy function could be replaced by one that retains timestamps. That's why I just wanted to check whether anyone at panic had seen this post.
I recall that there's some confusion between mod time and creation time between the platforms, or maybe it was a filesystem thing.. This fix seems to work correctly on macOS but I don't trust that it'll do the right thing on Linux or Windows.
edit4:OMG please disregard this whole post, it seems my unloading the zip did not overwrite. next post with info with updated PDC.... oof
Hey! We're looking for behavior of: timestamps only change if file is modified after last build?
This is not working then.
I unloaded the pdc-windows into my sdk/bin folder, built fresh, timestamps are all now (edited)
even files that don't get compiled
compile after deleting (fresh build):
compile after changing a line (not in any of these files):
strangely, a lot of the directories don't have their "date modified" updated, though the files in them do.
edit: seems fairly random? some things, not others. the font is fine!
edit2: yeah, I can't figure the logic for it.. images folder got updated, subdir did not...
while actual timestamps are supposed to match (?)
Compiled 11:18, refreshed 11:19. some things are fine, some got updated on compile, even though there were no changes (images etc)
It looks like data files (no compilation) get copied properly.
This one is strange. only the first file was unmodified 2nd build...
and the whole subdir still
For completeness I tested on mac and got the same results as @Grntrenchman did on Windows.
ImageTable get updated, but images, audio files, json and .bin do not.
Also, if I compile C for device, any existing simulator files are left untouched.
Would be nice to have imagetables unchanged too, but I also remember an earlier bug where pdt would not be updated when an source image was added to the image table. So I guess that was fixed by never caching those, and that's fine
I think this something I have to fix myself / look at rsync to fix. But I'll post this fyi.
We see:
left: pdx on playdate after transfer
right: pdx on mac hard drive
bottom: rsync verbose output
in the rsync output we can see that the simulator files are skipped (first character is a dot), but that the .bin file and .pdi file are transfered (> character. Strangely, the `.json. file is not transfered.
For the pdi and bin file, the reason for tranfer is listed as timestamp (t in the output). In finder, we see that indeed the timestamps do not match.
I'll have to look at rsync for that, I guess. Or do we know something about Playdate's Filesystem that makes these timestamp changes not stick?
Trying to transfer the files with finder seemed to properly update the timestamps on the device, but when running rsync after that, it would still copy the file.
Anyways, I think that your change to pdc is an improvement
It's tricky because a file could have the same timestamp and size yet still be different. In that case rsync would need to do checksums, which involves reading the whole of each file unless the filesystem or associated metadata already stores the checksum.
I'm not sure what the properties are of the Playdate's (FreeRTOS, uC-fs) filesystem are and how they map to the default filesystems on Mac/Windows/Linux.
