@User, Magic still seems to want to change the timestamps of unmodified blocks. Is this something you expect?

No, that's another behavior that I thought I already fixed. However, I think it has more to do with read-only status, which means that if you have the standard cells in a root-owned directory (the open_pdks default is /usr/share/pdk) then it may ignore them. Otherwise, if the location is readable/writeable by you, then magic doesn't know the difference between a project cell and a library cell.

No, everything I'm talking about is in the same RW folder. It's all full custom RW that it's trying to update the timestamps of

This might have to do with running DRC checks. It is one reason that I want to mostly scrap the timestamping feature in favor of a checksum feature. A proper checksum is more obviously reliable than a timestamp.

Yes, The time-stamping feature seems quite annoying. Sometimes it reports that the save it just related to timestamps but often it doesn't yes seems to only update the timestamp entries in the mag files anyway. I don't like it because it makes be wonder what may have inadvertently changed that it thinks it needs to save. Also, why are there multiple timestamp entries within the same file? E.g.

tom@tom-workstation:~/repos/mpw2-columbus-a0/columbus$ git diff
diff --git a/ip/bgr/lay/bgr_res_ratio_contact_array.mag b/ip/bgr/lay/bgr_res_ratio_contact_array.mag
index 691fafb..e4bd47c 100644
--- a/ip/bgr/lay/bgr_res_ratio_contact_array.mag
+++ b/ip/bgr/lay/bgr_res_ratio_contact_array.mag
@@ -1,6 +1,6 @@
 magic
 tech sky130A
-timestamp 1622917850
+timestamp 1623002814
 << error_p >>
 rect 18 0 26 96
 rect 32 0 40 96
@@ -18,7 +18,7 @@ rect 210 0 218 96
 rect 224 0 232 96
 use bgr_via_m1_m2  bgr_via_m1_m2_1
 array 0 7 32 0 2 32
-timestamp 1622916379
+timestamp 1621997247
 transform 1 0 0 0 1 3
 box 0 -3 26 29
 << end >>

The cell has a timestamp, listed at the top, and each of the uses has a timestamp. That is what in magic passes for versioning control. The parent cell writes down the timestamps of all the child cells, which then is supposed to match between the parent and child. Anyway, I think it makes more sense that each cell has a checksum, and only a checksum mismatch would cause magic to check the timestamp to see which cell is out of date, and otherwise magic would leave the cells alone.

Ah I see. Yes, I agree. I think that would make more sense.

Difficult? Probably not. Just need a bit of time to get it done. It's on the "fairly high priority" list but that's not as high priority as the four or five fires I'm trying to put out right now.

right