Why does preview change the ctime of a pdf, and how can I disable it?

Question

When I open a file in Preview, preview updates the ctime of the file. This seems to only happen once however, and as far as I can tell, nothing other than the ctime is changing. This is very frustrating because it's messing with scripts that are checking for modification to the file, even when no modification is happening.

Below is an example of what I'm seeing. I create a new pdf file called test.pdf, everything looks good. Then I open it with Preview, do nothing, and close preview. Now the file has an updated access and change time, but not modified. As far as I can tell, everything else about the file is identical, it's as if the ctime was touched for no reason. This effect seems to be cached in some sense, because if I open it again, only the access time is updated.

$ stat -x test.pdf 
  File: "test.pdf"
  Size: 47737        FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: ~~~  Gid: ~~~
Device: 1,3   Inode: 3220039    Links: 1
Access: Wed Jun 17 11:02:24 2015
Modify: Wed Jun 17 11:02:24 2015
Change: Wed Jun 17 11:02:24 2015
$ open test.pdf 
$ stat -x test.pdf 
  File: "test.pdf"
  Size: 47737        FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: ~~~  Gid: ~~~
Device: 1,3   Inode: 3220039    Links: 1
Access: Wed Jun 17 11:02:39 2015
Modify: Wed Jun 17 11:02:24 2015
Change: Wed Jun 17 11:02:39 2015
$ open test.pdf 
$ stat -x test.pdf 
  File: "test.pdf"
  Size: 47737        FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: ~~~  Gid: ~~~
Device: 1,3   Inode: 3220039    Links: 1
Access: Wed Jun 17 11:02:53 2015
Modify: Wed Jun 17 11:02:24 2015
Change: Wed Jun 17 11:02:39 2015

Is there any way to prevent preview from doing this, other than the naive copy the file first, and just look at the copy?

Answer 1

The filesystem and metadata can change when preview has write access to the file. The precise why is probably complicated, but you can prevent it by removing write access (chmod a-w test.pdf) and then using preview on the file. Note, the chmod updates the ctime as well.

---

My guess is that metadata fields like kMDItemUsedDates and kMDItemLastUsedDate are the reason for ctime being updated. You can use mdls test.pdf to check those details before and after your tests.

Answer 2

I've noticed this with images as well. When I open one in Preview, make changes to it, and "force quit" Preview, the changes persist even though I never saved them. I believe this happens because Preview autosaves your work by overwriting the original file. Most user don't notice this because when they close the program normally without saving, it reverts the changes and saves the file again.

I think there are two reasons why it does this, the first is that since Macs handle shutdowns and restarts very nicely (i.e. able to keep all your work open and load you right back to where you left off) then all Apple-made programs probably have to autosave to make sure the shutdowns happen as smoothly as possible without loosing any of our work.

The other reason (in my opinion) is because of the way Macs show previews of file contents in their icons. Usually whenever you make changes to a file, the icon is automatically updated to reflect the changes you made. This is particularly noticeable with pictures. I think (and this is just a wild guess) that the way Preview makes the icon update is by periodically saving the file. Doing so allows Finder to handle any necessary icon updates on its own without needing any special integration with Preview.

Why does it need to save the file immediately on open even though no changes have been made? I don't know for sure but I would guess it might have something to do with the way Preview handles files in memory: I've noticed that when you make a lot of changes to a high resolution image in preview, you actually loose a noticeable amount of free space on your disk. This means that Preview must store some of it's memory to disk rather than RAM.

Just a thought. Not sure if it's right or not.

Answer 3

For info, the ctime change is perhaps not directly related to the "Preview" application since the same thing happens when I open two videos from the command line using "open", which then launches VLC to show them. If I open them using VLC directly the ctimes are not changed. Also, if I open only one file either via "open" or directly with VLC, the times are not changed.

Curiously, if I use "open" on JPG files (which it opens in "Preview"), the effect is the same as described above for the PDF file: all the files' ctimes are updated regardless of whether the command opened just one or many files. I wonder why this is different for video files.

I don't imagine that "Preview" uses "open" (they both probably use lower-level Mac-specific I/O routines directly).

I echo the annoyance of the original poster above. The open operation seems to be messing around with the target files' inodes. Why this should be done for read-only operations is an Apple-only mystery. And unfortunate.