Does auctions.data corrupt because the new data is not completely overwriting the old?

[NullCase]

Everything looked good one second earlier.

I canceled an auction and now the data has an invalid entry.

It looks like the entry is removed just fine, BUT the list of entries is shorter, and now there's the "leftover" bit at the end.

Example:

You have the alphabet: abcdefghijklmnopqrstuvwxyz

Remove vowels and save over previous data:

Result using an inference based on observations: bcdfghjklmnpqrstvwxzuvwxyz

Add back the vowels: abcdefghijklmnopqrstuvwxyzuvwxyz

etc...

There's data at the end which accumulates.

Data below is after canceling one auction. Notice that the seemingly duplicated data is about one whole entry in length, but a bit less.

'5051':
  ==: com.robomwm.gpauctions.auction.Auction
  owner: 34ad6d8f-969e-4a78-98b5-68c8149b0234
  startingBid: 39600.0
  bids: []
  signLocation:
    ==: org.bukkit.Location
    world: world
    x: 1846.0
    y: 67.0
    z: -12.0
    pitch: 0.0
    yaw: 0.0
  claimID: 5051
  endTime: 1571728547473

051':
  ==: com.robomwm.gpauctions.auction.Auction
  owner: 34ad6d8f-969e-4a78-98b5-68c8149b0234
  startingBid: 39600.0
  bids: []
  signLocation:
    ==: org.bukkit.Location
    world: world
    x: 1846.0
    y: 67.0
    z: -12.0
    pitch: 0.0
    yaw: 0.0
  claimID: 5051
  endTime: 1571728547473

[NullCase]

abcdefghijklmnopqrst**uvwxyz**
bcdfghjklmnpqrstvwxz**uvwxyz**
abcdefghijklmnopqrstuvwxyz**uvwxyz**

Or if the auction closing had MANY bids, then the length of the file after saving would be significantly less.

like removing the consonants

aeiouy**ghijklmnopqrstuvwxyzuvwxyz**

[NullCase]

its like the file needs a telomere at the end. Some unique data that will never appear on its own. Make sure entries go before the telomere and that everything after is deleted. And then any time that shows up just delete everything after it (including copies of the telomere)

[RoboMWM]

It should be doing a full overwrite. https://github.com/RoboMWM/UsefulUtils/blob/582e687a93762f9dd1512606f4cc6aa8fc666e3f/src/main/java/com/robomwm/usefulutils/FileUtils.java#L67 StandardOpenOption.CREATE should overwrite the file whereas WRITE will do what you described above. I've used this class for file writing in another project which had the example you described (which resulted in the file being invalid yaml, so it wouldn't load), and that's how I resolved it. I'll doublecheck this...

[RoboMWM]

Ok, so Files#write accepts multiple params for OpenOptions. Looks like I need to add StandardOpenOption.TRUNCATE_EXISTING along with CREATE to overwrite I guess. Perhaps the defaults vary on the JVM? Just specifying CREATE was sufficient for me.

[RoboMWM]

What's your JVM version? java --version

[RoboMWM]

Ok, I made the change to use the defaults (specifying no options - which should use CREATE, TRUNCATE_EXISTING, and WRITE as per the javadoc)

Also as per the commit message, it will save an extra, new copy of the file every time it saves. This is a debugging feature.

https://ci.appveyor.com/project/RoboMWM39862/gpauctions/builds/28136581/artifacts

[NullCase]

yah, overwriting auctions.data has solved the 'extra data' problem.

rn I'm testing 1 hour auctions and there'll be probably 500 of them or more.

[NullCase]

I'm running Java 1.8.0.

I dont know yet (waiting on a response) but pretty sure the live server is also on 1.8