Update: Microsoft will be moving away from UserVoice sites on a product-by-product basis throughout the 2021 calendar year. We will leverage 1st party solutions for customer feedback. Learn more here.

Storage

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Enable immediate sync after changes on the Azure file share for Azure File Sync

    When I make a change on my server endpoint (Windows File Server), Azure File Sync initiates a sync session very quickly after file save, however for changes on the cloud endpoint (Azure file share), I have to wait at least 24 hours to have changes get synced down to my server endpoints.

    Please invest in features to initiate a sync session immediately after changes are made cloud-side, or at least increase the interval of sync from the Azure file share.

    2,403 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    113 comments  ·  Files  ·  Flag idea as inappropriate…  ·  Admin →

    As you mentioned, we initiate a change detection job once every 24 hours to enumerate the Azure file share and scan for changes. This is required for the Azure file share because Azure Files currently lacks a change notification mechanism like Windows Server has. Long term we will add this capability and have automatic immediate sync.

    There is now a way to trigger sync to happen on files that are placed directly in the Azure File share. With this new cmdlet you can point sync to particular files or directories and have it look for changes right then. This is intended for scenarios where some type of automated process in Azure is doing the file edits or migrations are done by an admin (like moving a new directory of files into the share). For end-user changes, the best thing to do is install Azure File Sync in an IaaS VM…

  2. Azure Files and Azure File Sync must support all unicode characters

    Azure Files and Azure File Sync do not support all unicode characters/characters supported by NTFS. This is particularly challenging when working with languages with non-Latin charactersets (see this post on issues supporting Japanese charactersets: https://social.msdn.microsoft.com/Forums/ja-JP/1ed730a9-9a4d-40dd-b84e-6f184e35e633/).

    This is also a significant adoption blocker when trying to adopt Azure File Sync, as file names on NTFS that are valid are rejected by Azure Files.

    143 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Files  ·  Flag idea as inappropriate…  ·  Admin →

    Thank you for the feedback! This is an issue we are aware of and are actively working to close this gap this year. Please feel free to continue to vote for this item to help us prioritize this effort.

    Thanks,

    Will Gries
    Program Manager, Azure Files

  3. Changeable "last-modified" file property on Azure File Service

    At the moment, our application stores its documents in a normal folder on a network share. The “Last Modification Time” of the files are important for internal version-handling, and our application heavily uses this file-property.

    Now we decided to move our documents into the cloud and we started using Azure File Service Preview. When we upload the documents via REST API, the “Last-Modified” property of the uploaded files get the current-time – that’s reasonable.

    But unfortunately afterwards the “Set File Properties” REST API call (https://msdn.microsoft.com/en-us/library/azure/dn166975.aspx) does not support the change of the “Last-Modified” property. (I tried both with…

    120 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Files  ·  Flag idea as inappropriate…  ·  Admin →

    Thanks for this feedback. Long term, we would like the File REST API for Azure Files to be a superset of the functionality available in SMB. In the short term, we are looking to close some of the gaps in the API that are most painful, like the file attributes that you can set via SMB but not File REST.

    We would appreciate further feedback on this item, in particular feedback on the things that you can do today over SMB but not REST to help us prioritize the order in which we close the gap!

    Thanks,

    Will Gries
    Program Manager, Azure Files

  4. consider azure premium files share for desktop applications which need heavy worloads, latency < 1ms, high I/O but only need 100gb size

    We have a .net desktop application for exporters. and run it well in our pc and Area network. We now built a premium files share storage with 500g
    and make a share path with our local machine, we found it works become very slow. if we only open one database file and edit,update one item, it only a little slow. but when we will open,create,update many item and many files. it become very very slow. We also do it from vm machine. when we excute out desktop allpication in vm machine. it is fine. but when we link files share…

    83 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Files  ·  Flag idea as inappropriate…  ·  Admin →

    Hi folks,

    While we have made premium file shares generally available, we agree there is ongoing performance work associated with them.

    One of the big performance related items is one you touched on in the description: performance when doing activity on many files at once. Azure Files, on both premium and standard, performance best for read/write operations with few handle/metadata operations (i.e. databases) and less good for scenarios that require lots of handle and metadata operations. We are working to improve this performance category and hope to have more to share soon.

    Thanks,

    Will Gries
    Program Manager, Azure Files

  • Don't see your idea?

Feedback and Knowledge Base