When getting content from an endpoint in Azure Functions, I used to be able to save stuff locally and then handle that stuff before passing it to output in Azure Functions.
Now I have this setup:
1: What happens, when I call my endpoint
2: My function code
3: My call to the function
4: The contents of C:\Local\Temp AFTER the function has been called
According to my function code (2) the file C:\local\Temp\cspcustomer.parquet should exist, but when trying to read the file I obviously get an error.
Furthermore, when looking at the actual contents of C:\local\Temp in Kudu (4), the file is not really there.
My question is, where is my file, so I can continue my work?
CodePudding user response：
Azure function app has different file system storage locations. Those are
D:\local
This is local temporary storage, and you cannot share any file from this storage. Temporary storage meaning, this storage goes away as soon as you delete your Azure function from the Virtual Machine. You can store up to 500MB data here.
If your Azure function has to say 3 instances, each one of these instances will actually run on its own virtual machine, and ultimately, each instance will have its own D:\local storage up to 500MB.
D:\Home
This storage is shared storage. There are no restrictions, All your Azure Function app instances will have access to this storage. In this storage case, If you will delete your Azure function app or moved it to somewhere else then the storage will not go away like in the case of D:\local. The storage will remain as it is.
You can use the Home directory instead of Local.
I can able to see the parquet file which is available in Home Directory
Refer here
CodePudding user response：
The file that cannot be found is one of the dll files in Import-Parquet and not the temp-file created by the code. The temp exists in the container running the code, as @DelliganeshS-MT points out.
This question remains: How come, that a custom C# runs perfectly fine on both Windows and Linux (tested in Github Actions) will not run in Azure Functions?
The module PSParquet is on the PowerShell Gallery. If anyone has an idea as to what is causing this, I would be more then happy to adjust the code accordingly.
I'm pretty sure this is not some sort of dll-hell. I highly doubt that Parquet.dlland IronSnappy.dll are already in use in Azure Functions, which might cause an error like this, as described here: https://docs.microsoft.com/en-us/powershell/scripting/dev-cross-plat/resolving-dependency-conflicts?view=powershell-7.2