# deleteFile strange behavior

**URL:** <https://forum.juce.com/t/deletefile-strange-behavior/27757>\
**Category:** Audio Plugins\
**Created:** [May 20, 2018, 6:48pm UTC](https://forum.juce.com/t/deletefile-strange-behavior/27757 "2018-05-20T18:48:33Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![crandall1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/crandall1/32/157_2.png) [@crandall1](https://forum.juce.com/u/crandall1)\
**Post date:** [May 20, 2018, 6:48pm UTC](https://forum.juce.com/t/deletefile-strange-behavior/27757/1 "2018-05-20T18:48:33Z")

</div>

I’m putting this in the Audio Plugins category, since it seems to be a plugin-related behavior.

Forgive me if I’m doing something stupid here, but it seems that if I create a file (in this example, for global settings), only the instance of the plugin that created the file can delete it. Example behaviors:

1. On first instance, the plugin checks to see if a global settings file exists, and if it doesn’t, it creates one. In hosts that run a validation (like Bitwig), they effectively instance the plugin completely, so this settings file is created. So future instances can no longer delete or alter it, only append it.

2. If I make it so the settings load from default if there’s no global settings file, and later write a settings file, any instance but the one that created it can not overwrite it.

In that example, if existsAsAFile returns true, result returns false. I want the prefs to be per user, obviously, so I’m using the userApplicationDataDirectory special location, but I’ve tried it with pretty much everything including root, and it just won’t delete. While I’m not that interested in deleting the file, I do need to use replaceWithText(), which has a delete() in it.

Note this is Win10; I haven’t tried it on my macOS machine yet.

EDIT: Tried it on my Mac, and it works fine; replaceWithText() and delete() work as expected. So this is a Windows 10 issue, it would seem.

---

<div class="post-metadata">

**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\
**Post date:** [May 20, 2018, 8:36pm UTC](https://forum.juce.com/t/deletefile-strange-behavior/27757/2 "2018-05-20T20:36:10Z")

</div>

I can’t explain the behaviour, but a workaround without deleting the file might be:

```auto
FileOutputStream output (file);
output.setPosition (0);
output.truncate ();
output.writeText (text, false, false, nullptr);

```

HTH

EDIT: use writeText instead writeString according to docs…

---

<div class="post-metadata">

**Author:** ![crandall1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/crandall1/32/157_2.png) [@crandall1](https://forum.juce.com/u/crandall1)\
**Post date:** [May 20, 2018, 8:43pm UTC](https://forum.juce.com/t/deletefile-strange-behavior/27757/3 "2018-05-20T20:43:10Z")

</div>

Ah, that did it. I had tried something along similar lines early on, but apparently didn’t try it hard enough.

Anyhow, the JUCEateers can consider this an official bug report. delete(), replaceWithText(), and related methods are apparently only accessible by the instance that created the file in Windows 10 (latest public version).

---

<div class="post-metadata">

**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\
**Post date:** [May 20, 2018, 8:44pm UTC](https://forum.juce.com/t/deletefile-strange-behavior/27757/4 "2018-05-20T20:44:35Z")

</div>

Thanks for the report, I am sure, the JUCE team will pick that up in the coming days!

---

<div class="post-metadata">

**Author:** ![crandall1](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/crandall1/32/157_2.png) [@crandall1](https://forum.juce.com/u/crandall1)\
**Post date:** [May 20, 2018, 8:54pm UTC](https://forum.juce.com/t/deletefile-strange-behavior/27757/5 "2018-05-20T20:54:37Z")

</div>

Per your edit above, I was initially using replaceWithText() but with your sample code, JSON::writeToStream() worked more better, so I switched to that, since our globals are JSON anyhoo.

---

<div class="post-metadata">

**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\
**Post date:** [May 20, 2018, 8:57pm UTC](https://forum.juce.com/t/deletefile-strange-behavior/27757/6 "2018-05-20T20:57:38Z")

</div>

That makes sense. To be honest, I was unsure which one to choose, the docs say writeString behaves different from what you expect, that’s why I switched it to writeText.  
But this way you don’t have to decide which one… much better 😉

---

<div class="post-metadata">

**Author:** ![ed95](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ed95/32/7635_2.png) [@ed95](https://forum.juce.com/u/ed95)\
**Post date:** [May 21, 2018, 9:09am UTC](https://forum.juce.com/t/deletefile-strange-behavior/27757/7 "2018-05-21T09:09:29Z")

</div>

I’ll take a look.

---

<div class="post-metadata">

**Author:** ![ed95](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ed95/32/7635_2.png) [@ed95](https://forum.juce.com/u/ed95)\
**Post date:** [May 21, 2018, 10:22am UTC](https://forum.juce.com/t/deletefile-strange-behavior/27757/8 "2018-05-21T10:22:18Z")

</div>

I’ve created a basic audio plugin project in the Projucer and added the following lines to the `AudioProcessor` constructor:

```auto
auto testFile = File::getSpecialLocation (File::SpecialLocationType::userApplicationDataDirectory)
                     .getChildFile ("TestFile.settings");

if (! testFile.existsAsFile())
    testFile.create();
else
    jassert (testFile.deleteFile());

```

I’ve tried loading multiple instances of the VST in both the JUCE AudioPluginHost and Waveform 9 on Windows 10 and I can’t reproduce the `deleteFile()` failing. Can you put together a minimal code example that reproduces the problem, or try adding the lines above to a basic audio plugin template and stepping through in the debugger to see if it succeeds?