DOpus.FSUtil.GetTempFile prefix suffix position opposite

Set TempFile = DOpus.FSUtil.GetTempFile("prefix-", ".suffix", "D", DOpus.listers.LastActive)
DOpus.Output TempFile.Path



TempFile.Path return is short path

It'll use whatever your operating system reports as the temp folder.

Does it cause a problem?

TempFile.Error return 0
DOpus.Output TempFile.Write("test") outout 4

everything is normal

Set Blob =DOpus.Create.Blob
Set TempFile = DOpus.FSUtil.GetTempFile("prefix-", ".suffix", "D", DOpus.listers.LastActive)
DOpus.Output TempFile.Path.LongPath
DOpus.Output TempFile.Error
DOpus.Output TempFile.Write("test 中文")
TempFile.Seek 0
DOpus.Output TempFile.Read(Blob, TempFile.Size)
DOpus.Output Blob.Size
DOpus.Output TempFile.Size
DOpus.output DOpus.Create.StringTools.Decode(Blob, "utf-8")




Press F5 in the CLI to run the script, occasionally get the correct result.

You think this error is due to the short path being used? If so, what makes you think it's due to that?

Or are there two different issues here? I'm a bit lost, to be honest.

You didn't find the path format that returned?
Short path + long file name.

In accordance with the instructions in the manual I think that the value returned should be like this:

The path format is <whatever your Windows installation says is the temp folder> + <a name generated by Opus>.

If your Windows installation is using a short name for the temp folder, that's not something Opus is doing. It'll be down to how Windows is configured on that machine. But it's also not something that should matter in any way, since the path is valid and works.

Set TempFile = DOpus.FSUtil.GetTempFile("prefix-", ".suffix", "D", DOpus.listers.LastActive)

Actual file name

According to the function, the correct name I think is

If the function does not use any parameters, will get the name I think the correct.

That's an error in the documentation, which we'll fix. The first two arguments are documented the wrong way around.

(Suffix comes first since it lets you specify that on its own without having to specify any of the other arguments, and the suffix (file extension) is usually the only thing that might needs to be changed in order to make other programs recognise the temp-file as the intended format.)

So were there three issues here or were the other details unimportant? Does anything still need to be resolved?

The "Read" method object of the "File" object returned by GetTempFile is not able to read the file content correctly.

Need to close the file, then reopen it again to read the content correctly?

Currently, yes (and you'd need to avoid GetTempFile's delete-on-close mode at the moment), but we'll make this easier in the next update.

  • If you check TempFile.Error after your TempFile.Read call, you'll see the read call actually failed. The File returned by GetTempFile is write-only at the moment, but we'll make it read-write in the next update.

  • We'll also make it so that when File.Read fails, the Blob size is set to zero, and (if it's returning a number) it returns 0 as the amount read instead of nothing at all. That'll make it easier to know the Read failed.

  • We'll also make it so that FSUtil.OpenFile can specify that it's OK for the file to be flagged for deletion. That will make it possible to open the delete-on-close temp file in a second File object if you want to have separate read and write objects (although you'll also be able to use a single object as well, if you want).

  • Your TempFile.Seek(0) call wasn't doing anything, as that means "move the pointer 0 bytes from its current position". To move the pointer to 0 bytes from the beginning of the file, you should call TempFile.Seek(0, "b") instead.

In the next version, this will work:

This will work in the next version as well:

1 Like

Those changes are in the beta released today: Directory Opus 12.24.1 (Beta)

The documentation has also been fixed and improved. (Only the manual that comes with the beta, e.g. via F1 help. The copy on the web will be updated later.)