files do not seem to like me :-(

Sorry for bothering you - but I am completely unable to get even simple file operations working.

The following code

const Storage = require('Storage');
  function compareFileWith (expectedContent) {
    if (Storage.read('4testing') != expectedContent) {
      print('>>>> file does not look as expected');
      print('>>>> expected "' + expectedContent + '"');
      print('>>>> got "' + Storage.read('4testing') + '"');
    }
  }

/**** create file ****/

  let TestFile = Storage.open('4testing','w');

  TestFile.write('Hello, World!');
  compareFileWith('Hello, World!');

/**** read file ****/

  TestFile = Storage.open('4testing','r');

  let readText = TestFile.read(5);
  if (readText != 'Hello') {
    print('>>>> reading "4testing" failed');
    print('>>>> expected "Hello", got "' + readText + '"');
  }

  TestFile.read(2); // skip ', '

  readText = TestFile.read(5);
  if (readText != 'World') {
    print('>>>> reading "4testing" failed');
    print('>>>> expected "World", got "' + readText + '"');
  }

  TestFile.read(2); // skip '!' and go beyond EOF
  print('read after EOF: "' + TestFile.read(4) + '"');

/**** write file ****/

  TestFile = Storage.open('4testing','w');

  TestFile.write('Welcome');
  compareFileWith('Welcome');

  TestFile.write(', World!');
  compareFileWith('Welcome, World!');

/**** extend file ****/

  TestFile = Storage.open('4testing','a');

  TestFile.write('\nHere I am!');
  compareFileWith('Welcome, World!\nHere I am!');
print('finished');

produces this output

read after EOF: "undefined"
>>>> file does not look as expected
>>>> expected "Welcome"
>>>> got "Hello, World!"
>>>> file does not look as expected
>>>> expected "Welcome, World!"
>>>> got "Hello, World!"
>>>> file does not look as expected
>>>> expected "Welcome, World!
Here I am!"
>>>> got "Hello, World!"
finished

which basically means that an existing file can not be overwritten using Storage.open(filename,'w') followed by file.write(newcontent).

Does anybody see what I'm doing wrong?

you are mixing older direct Storage.read approach documented also here https://www.espruino.com/Reference#Storage with newer file=Storage.open, file.read approach which is using hidden numbered suffixes in file names so I guess these are different types of files

and btw in future don't hesitate to reuse your existing 'Andreas_Rozek vs files' forum topics while still experimenting with Storage files ;-)

Well, Gordon mentioned I should not mix Storage.write with file-based operations.

Is Storage.read forbidden as well? If so: how do I determine the size of a file?

these are simply different types of files - StorageFile based operations are implemented on top of multiple Storage files with numbered suffixes see e.g. this topic http://forum.espruino.com/conversations/341825/#15028001 so mixing them while expecting them to have same file names does not work

I understand...

But again: how do I then determine the size of a StorageFile? Hopefully, I won't have to read it character by character until EOF?

Indeed it looks like there is no api call for getting the size but I followed link provided by Robin in one of yours previous storage based topics and found this reply http://forum.espruino.com/conversations/329768/#14577636
So if you really need the size now you can possibly iterate over those numbered file parts and add the length number as a workaround.

Well,

thanks for the hint...it sounds tedious, but - at least - should not take too long.

What I will now have to test, though, is whether there is a limit of "file parts" because of the range of the added "number". Having a limit would be a killer for measurements at regular intervals (e.g. current GPS position) which would simply be added to an existing file: 253 or 254 extensions would be far too few

If the size of each record is fixed I would preallocate the file for specific period/number of records and used just https://www.espruino.com/Reference#l_Storage_write directly and then just fill it later record by record. Once full I'd start with another preallocated file. I'd keep current offset in variable in RAM or find where is last record by scanning the data if the variable got lost (e.g. after reset or dead battery). That way I wouldn't need to know the length. If the record is variable I'd include length into each record.

Yes, whatever approach I will choose it will require my own implementation.

At first, I had the idea of using StorageFile, but (given the problems I encountered) I will definitely stay away from them now.

Thanks anyway for your help!

I'm pretty sure StorageFile allocates 4k pages (it doesn't add a page per write command) - so 254*4k is one Megabyte. Is that really too small?

Gordon,

not the file size is the problem, but the limited number of append operations (provided that my theory is correct!)

I would perhaps have to write, let's say 1260(a few bytes), e.g. 12*60*100 = 72kB - but in 12*60 = 720 steps.

This can not be done incrementally, can it? So I will have to preallocate room for the longest sequence I expect and keep track of what I've already written myself - carefully avoiding writing to offset 0 as that creates a new file (well, it wastes 1 byte, but that's ok)

I'm not sure I understand - could you give an example?

If you call StorageFile.write 10000 times, writing one byte each time, it'll use just 3 files worth of data. The file number does not increment based on how many writes you're doing, it's based on how many 4k pages you're using.

The restriction on using 0xFF in StorageFile files is specifically so they can have that behaviour.

Ah, now I understand!

Thanks for clarification!

But what about the file name: you are using the last character of the file name for segment numbering (starting at 0x01, as far as I understood). Do these names collide with the names of of "normal" files? And does this method actually reduce the usable length of file names to 6 (1st char has some semantics, last one as well, and there are only 8 chars available in total)?

Do these names collide with the names of of "normal" files?

Yes, they do collide. However unless you're getting to bigger files (>128kb) the last character isn't even a normal ASCII character so the chances of collision are super minimal.

How you use the first 7 chars of the filename is up to you, but I would imagine you could find a way to ensure that the first 7 chars are not the same as the first 7 chars of another file on the watch.