SAFE NFS - how to handle deleted entries

[happybeing]

Looking at the NFS API I can see no way to get the list of entries without it including entries for deleted files.

UPDATE: Ah, I’ve just rememberd I’m still using safe_app_nodejs v0.8.1, so maybe this is different in v0.9.1? I think I’ll bump back up to 0.9.1 anyway.

The way I am testing if an entry has been deleted is to try nfs.fetch(). If the entry has been deleted, this gives an unhelpful error message/code which looks like it could happen for other reasons:

-1: Core error: Error while serialising/deserialising: Deserialise error: IoError: failed to fill whole buffer

Is there a better way to test if an entry has been deleted?

And with a regular MD (rather than NFS API) what’s the official way to determine that an entry has been deleted? Seems a bit brittle to use ‘-1 serialisation error’ if that might be caused in other ways.

Also, while I’m asking. Do you know if the reason the Web Hosting Manager requires files to be deleted before re-uploading them is due to an NFS bug? I’m finding that update() rarely works an an existing entry, and I note that the WHM only ever does it on a deleted file. This may be my bug, but as far as I can tell that isn’t the cause. Still investigating though.

[hunterlester]

@happybeing

Looking at the NFS API I can see no way to get the list of entries without it including entries for deleted files.

Right, the only way might be to use get() to see if the entries value is an empty Uint8Array, { buf: Uint8Array(0), version: 1 }.

Good thing to bring up though.
We’ll have to see how this all changes when the MD data type is made to be append-only.

@happybeing

I’m finding that update() rarely works an an existing entry, and I note that the WHM only ever does it on a deleted file.

What are the conditions under which it doesn’t work on an existing entry?
I’ve not had issue yet with update().

I’ll have to refresh my memory about what WHM is doing.

[happybeing]

I’ve managed at some point to create a file, but so far I think never updated an existing entry. They always end up with an odd state.

Right now I can create a new file:

• open() / write() … / close() and insert()

Without errors, but there is no data in the file. In fact if I look at the File structure I can see it has metadata (valid modified and created dates) but the datamap address is always zeros (size is zero as well).

I can also open() the file for write, write(), close() and update(). The version gets bumped but the File structure remains with a datamap of zeros and size 0.

Note: this is different to a deleted entry. I have successfully deleted an entry and that looks as you describe here:

@hunterlester

Right, the only way might be to use get() to see if the entries value is an empty Uint8Array , { buf: Uint8Array(0), version: 1 } .

The odd thing is that although it isn’t doing what I expect, there are no errors from the API. I’m obviously doing something daft but finding it hard to figure out atm.

I’ll keep at it for now. Thanks for the response @hunterlester

[hunterlester]

@happybeing

Right now I can create a new file:

• open() / write() … / close() and insert()

Without errors, but there is no data in the file. In fact if I look at the File structure I can see it has metadata (valid modified and created dates) but the datamap address is always zeros (size is zero as well

Do you have a code snippet I can look at?

[happybeing]

It’s OK thanks @hunterlester, I cracked it. One pesky missing await meant I was doing insert/update before the close had completed. Might be worth trapping that with a flag in the File object returned by open(… writable) so insert/update before close can generate an error? Actually, no flag needed, you can just check if there is an immutable data ref. Ah, no, zero length files would also look like that I think, so you do need to check if close was called or not.