30

This seems like it must be a permissions issue on my machine. After a systems update on Windows 10, when I run:

import matplotlib.pyplot as plt
#make figure
plt.plot([1,2,3,4])
plt.ylabel('some numbers')

#save
plt.savefig("./figs/my_plot.jpg")

It will create the figure the first time the code is run. If I make a change to the code (e.g. change label) and then re-run, the plot shown in a Jupyter Notebook is updated, but the file saved on my machine is not! This is a new issues as of today, after a systems update was pushed out, so this seems like a likely culprit. Any insight for me to fix this issue, besides creating a new file name every time a change is made?

EHB
  • 1,127
  • 3
  • 13
  • 24

3 Answers3

30

TLDR: The photos WERE being overwritten, but the date was kept the same as the original file, due to a quirk of windows when a folder has lots of photos.

Jon's answer from 10/2/2015 did the trick for me. https://superuser.com/questions/147525/what-is-the-date-column-in-windows-7-explorer-it-matches-no-date-column-from/335901#335901

Basically windows detects lots of pictures in a folder and "optimizes" said folder for pictures. This means the column displayed is Date rather than Date Modified as it would be for a folder "optimized" for documents. Date takes the earlier of Date Created and Date Modified. As Date Created doesn't change when matplotlib .savefig overwrites a file the Date column never changes.

To resolve this issue I customized the folder for documents. To do this select the folder and open the properties window. Navigate to the customize tab then select documents under "optimize this folder for."

Elegant Code
  • 678
  • 6
  • 18
bbade
  • 324
  • 3
  • 5
  • 3
    That is, It is updating, but it looks as it's not, because the date modified is not being shown as usual (regular folders). This was my case, thanks for sharing the information. – Jairo Alves Oct 17 '19 at 21:48
  • In case the code is to be shared with others, it is safer to remove the file as @iblasi suggested. You cannot be sure that the person you share your code with has customized their folder accordingly. – csar Apr 28 '20 at 10:46
  • For some files DateCreated stays the same even if I delete the files (from Python or from Windows itself) prior to saving new files with the same name. This is just weird. Seems like a bug in Windows, I don't know. So... no matter what you optimize your folder for, this is just unreliable. DateCreated cannot be trusted, it seems. – peter.petrov Jan 09 '21 at 00:30
16

It may be simple and stupid, but I will just do the following:

import os
import matplotlib.pyplot as plt
#make figure
plt.plot([1,2,3,4])
plt.ylabel('some numbers')

#save
strFile = "./figs/my_plot.jpg"
if os.path.isfile(strFile):
   os.remove(strFile)   # Opt.: os.system("rm "+strFile)
plt.savefig(strFile)

It may be quite hard to use directly "rm" as system command line, but you can use any other option similar to that one.

But being honest it's strange that matplotlib does not overwrite the file.

EDIT

I see that you are using windows, so you may use "del" as delete command line instead of "rm" for unix.

iblasi
  • 1,269
  • 9
  • 21
  • This is useful - I'll accept in a few days if no one has a Windows-based explanation for what has changed, and how to fix. A great work-around. – EHB Feb 28 '18 at 23:20
  • 2
    uhm, don't use `os.system(rm...` (potential for shell expansion), when there is a perfectly good python function `os.remove` – Radovan Garabík Jun 25 '18 at 11:00
  • 1
    I agree. I update the code with original ```system``` call as optional – iblasi Jun 25 '18 at 14:20
  • Decent solution, except it doesn't work for me. Even when removing the files (with os.remove) before saving new versions, Windows will still keep the old date, at least some times. bbade's answer explains the problem, though. So I guess one can just try to stop worrying about whether the files are updated or not. – Elias Hasle Jun 21 '19 at 06:32
8

Just add "plt.close()"

plt.savefig("./figs/my_plot.jpg")
plt.close()
Maestre Sanmiguel Colombia
  • 105
  • 1
  • 1