-1

I have code where I'm writing to a file, and the next time I run the code after the code successfully runs, it gives me the following error:

PermissionError: [WinError 32] The process cannot access the file because it is being used by another process:'minicube_HE022222.fits'

So every single time I have to change the name of the fits file and then there are no errors. It's just really frustrating having to change the filename everytime I run the code. Here is my code snippet:

new_hdu = fits.HDUList([fits.PrimaryHDU(mini_data), fits.ImageHDU(mini_error)])
new_hdu[0].header = qso_header
new_hdu.writeto('minicube_HE022222.fits',overwrite=True)
new_hdu.close()

I get the error at: 

new_hdu.writeto('minicube_HE022222.fits',overwrite=True)

I close the file after writing to it but that doesn't help either. Any suggestions are appreciated.

Update:

Here is another portion of a code where this error occurs:

hdus=[]
hdus.append(fits.PrimaryHDU())
hdus.append(fits.ImageHDU(par[0,:,:],name='amp_Hb'))
hdus.append(fits.ImageHDU(par[1,:,:],name='amp_OIII5007'))
hdus.append(fits.ImageHDU(par[2,:,:],name='amp_OIII5007_br'))
hdus.append(fits.ImageHDU(par[3,:,:],name='amp_Hb_br'))
hdus.append(fits.ImageHDU(par[4,:,:],name='amp_Hb1'))
hdus.append(fits.ImageHDU(par[5,:,:],name='amp_Hb2'))
hdus.append(fits.ImageHDU(par[6,:,:],name='amp_Fe5018_1'))
hdus.append(fits.ImageHDU(par[7,:,:],name='amp_Fe5018_2'))
hdus.append(fits.ImageHDU(par[8,:,:],name='m'))
hdus.append(fits.ImageHDU(par[9,:,:],name='c'))
hdu = fits.HDUList(hdus)
hdu.writeto('subcube_par_HE12_lsq.fits',overwrite=True)

It's only at the 'xxx.writeto' where the error occurs. If there's another way I can write to a file or update the existing file with the new data, please let me know. Thanks

Robin Dhillon
  • 43
  • 9
  • In general, the Windows I/O model requires shared read/execute, write/append, and delete access to files, i.e. all File objects with data access to a file have to cooperate. Windows Python itself shares read and write access, but not delete access. I don't know what `fits` does, or why a File remains open after your script exits, but you'll want to look for `CreateFile` calls. In particular, look for the access they request (e.g. `GENERIC_READ` or `DELETE`) and the access they share (e.g. `FILE_SHARE_READ`). – Eryk Sun Jul 06 '18 at 23:48
  • Quick meta note: On StackOverflow you can format code blocks by indenting each line four spaces. Backticks are only for formatting words within a pargraph as code `like this`. I've cleaned up your formatting for you. See https://stackoverflow.com/editing-help#code – Iguananaut Jul 07 '18 at 19:46
  • Where do the arrays `mini_data` and `mini_error` come from? – Iguananaut Jul 10 '18 at 18:07

1 Answers1

0

As this comment notes, the way file I/O works on Windows is such that you can't overwrite a file if you have that file already open in another process. Are you writing this file and opening it in another program? If you have that file open in any other program then you can't overwrite it.

Do you need to be able to make in-place updates the file while it is open in another program? If so that may still be possible, but you can't use HDUList.writeto() as that effectively deletes the existing file and replaces it with a new one (rather than updating the existing file in-place).

Also, how are you running this code? Is it in a script? You mentioned having to change the filename every time but you could design things such that you wouldn't have to. I noticed that you have the filename hard-coded in your code, and that can and should be fixed if you want to write a more versatile script. For example, you could accept the filename as command-line argument. You could also have the script append a number to the filename or something if the file already exists.

All that said, you should figure out why you have the same file open in multiple programs.

One small usage aside:

The new_hdu.close() in your example doesn't actually do anything. The HDUList.close() method only makes sense when you open an existing FITS file from disk. Here you're creating an HDUList (the data structure representing a FITS file) in memory, and calling the high-level HDUList.writeto() which opens a file, writes the in-memory data to that file, and the closes the file. So the .close() in this case is a no-op. I'm guessing maybe you added it to try to fix your problem, but it's actually not relevant.

Iguananaut
  • 21,810
  • 5
  • 50
  • 63
  • Yeah, I'm kinda new to this so I was trying to somehow close it with the hdu.close(), which like you said, doesn't work. Anyway, I'm running the code in a script on Spyder. It gives the same error when nothing except Spyder is open as well. I could append something onto the name but that'll just keep creating new files, which I'm trying to avoid. – Robin Dhillon Jul 07 '18 at 22:46
  • How are you running in the context of Spyder? I think you need to update your question with more details and / or look into what other processes are accessing these files (if, for example, the file is in a directory tracked by Dropbox or Google Drive, or if it's being scanned by a virus scanner that can also cause this). – Iguananaut Jul 09 '18 at 08:30
  • All good, I fixed it. I just pass the error now and works everytime. Thanks. – Robin Dhillon Jul 09 '18 at 16:57
  • The following is what I do. Would it do the trick? try: hdu.writeto('filename.fits',overwrite=True) except PermissionError: pass – Robin Dhillon Jul 09 '18 at 20:18
  • Well if you get an exception it means you didn't actually write anything. You still just have something that's leaving the file open somewhere... – Iguananaut Jul 10 '18 at 08:46
  • Perhaps it would help if you showed more of your code. It's clear you haven't posted your full code. – Iguananaut Jul 10 '18 at 08:47
  • The code I posted above is an example. I'll post another portion of the code where I get this error; check update above. Do I need to post the full code? Because all of the rest works. It's just where I'm writing to a file where this error occurs. – Robin Dhillon Jul 10 '18 at 14:57
  • Are you sure you don't have a virus scanner or Dropbox or something accessing the files? The only answer I can possibly give you is that some other process on your system is accessing those files when you're trying to write to them. – Iguananaut Jul 10 '18 at 18:06
  • I've also run into this problem before with automated backup software (e.g. crashplan). – Iguananaut Jul 10 '18 at 18:08