@浩太郎 石田 Welcome to Microsoft Q&A Forum, Thank you for posting your query here! Firstly, apologies for the delay in responding here and any inconvenience this issue may have caused.
Is there a rename operation in the REST API?
Not at this time.
Additional information: The FileREST API started out as a clone of the BlobREST API with a hierarchical namespace grafted on, Azure Files is obviously a different and separate service than Azure Blob storage or Azure Data Lake storage. We have a general effort to keep the various REST protocols broadly aligned, however, our view is, that ultimately our separate and distinct storage services need to follow the requirements of the use cases of the customers, and as such, the protocols will look different over time.
The main way we expect customers to use Azure Files is to mount their file shares with SMB or NFS and use normal file system API calls in the operating system that using. For most customers, this will look like one of two things:
- End-users are mounting their Azure file shares on their desktop workstation, and using file shares directly through File Explorer/their local applications (Word, Photoshop, AutoCAD, etc.).
- Line-of-business applications are using their Azure file shares to host shared data necessary for the application to run. These applications may be running on end-user workstations as well, or they may be hosted on Windows or Linux server VMs.
In general, when we are talking customers have already written applications that they want to continue using, rather than rewriting their application with a new set of unfamiliar APIs. We do see new application development against Azure Files as well, where customers use native file system APIs for maximum portability – if you talk to a file share using regular OS calls, you can pick it up, and run it on any file share anywhere (Azure file share, file share hosted in NetApp Files, a file server VM, a file share in a different cloud, etc.). It’s also quite popular in container scenarios to mount Azure file shares within the containers and use native file system APIs to talk to shared storage.
In this case, as you linked to the SDK for .NET, you could use the System.IO APIs to read/write/modify files. These APIs get translated to native file system APIs for the platform you’re on and sent out by your OS over SMB (or NFS). Java/Python/etc. all do the same thing of wrapping the underlying file system APIs with language idiomatic APIs that make it easy to talk to storage.
When it comes to new software development, we position FileREST as being most useful for first and third party partners building value-added services for Azure Files. Two great examples of first party services that use FileREST to provide additional value for Azure Files are Azure File Sync and Azure Backup, although we are working with other teams across Azure and the rest of the industry to provide value-added solutions for Azure Files. There are multiple reasons why having a REST protocol is useful for cloud services that add value to file (scale, perf, etc.). You can also use FileREST to write your own applications or services, but the rationale for doing this as a customer is much less. Having a rename operation in the FileREST protocol is actually something we are currently working on, although I do not have an ETA to share.
You may upvote this similar feedback request: https://feedback.azure.com/forums/217298-storage/suggestions/14607120-make-it-possible-to-rename-any-resource. All the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.
If you are looking to rename Azure File Share you can perform using Azure Storage Explorer tool.
Hope this helps!
Kindly let us know if the above helps or you need further assistance on this issue.
------------------------------------------------------------------------------------------------------------------------------
Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.