locked
Remove folder with lots of files from virtual filesystem RRS feed

  • Question

  • I'm having trouble removing a rather huge folder from the virtual filesystem of an Azure Web App (Standard Tier). It's got many many thousands of tiny files. API calls to list the filesystem timeout, FTP takes forever, Kudu command prompt doesn't seem to do much either (tried rm -rf).

    Are there any other options besides destoying the site and redeploying in a new web app?

    Thursday, January 31, 2019 10:45 PM

Answers

  • Thanks for the update. Yes, I did consider that. See also my original question. I'm now trying to add a deployment slot, deploying into that, swapping and then dropping the slot. This should limit downtime for the customer. However, there was so little disk space in the app service that this wasn't really an option. There's a bout 2Gb free now so that should be enough.
    Tuesday, February 5, 2019 11:25 PM

All replies

  • Is removing the whole folder an option to you - and recreate the folde?   If yes, try that.

    Suwatch

    Thursday, January 31, 2019 11:59 PM
  • Yes, that is an option and I have tried that. So far with no luck. The command just seems to take too long to complete. What would be the best way to delete a directory?
    Friday, February 1, 2019 7:04 AM
  • Share us the site name (here or indirectly).   Also share the path to folder that you want to remove.   We will try to remove the folder for you.   BTW, once we remove you won't be able to get the files/folders under that folder back.  Confirm that you really want us to remove for you.

    Suwatch

    Friday, February 1, 2019 7:14 AM
  • Thanks, the problem is in both the production apps (those apps not postfixed with acc) in the app service for:

    https://dummy08551a06fd0c.azurewebsites.de

    The paths are:

    • home\site\wwwroot\App_Data\AzureCache\app_data
    • home\site\wwwroot\App_Data\AzureTemp\app_data

    I confirm that it's fine to permanently remove these folders and everything in them.

    Thanks!

    Monday, February 4, 2019 2:37 PM
  • Since we will be removing the files, to ensure we are talking about the same AppServices and prove ownership, could you follow the "ensure site" step in https://github.com/projectkudu/kudu/wiki/Reporting-your-site-name-without-posting-it-publicly and let us know when done.

    NOTE: since this is DE national cloud, the process may take a little longer.


    Suwatch

    Monday, February 4, 2019 7:32 PM
  • I've added a LogFiles/temp.txt file as instructed to both the www and the edit site that need to have the folders removed.

    Thanks

    Tuesday, February 5, 2019 8:20 AM
  • We have started removing the folders you mentioned - due to the sheer amount files (under webanalytics folder) and remote filesystem nature, it may take many hours.   Do you consider create a new site and ported content and setting there?   It might be faster ..

    Suwatch

    Tuesday, February 5, 2019 10:27 PM
  • Thanks for the update. Yes, I did consider that. See also my original question. I'm now trying to add a deployment slot, deploying into that, swapping and then dropping the slot. This should limit downtime for the customer. However, there was so little disk space in the app service that this wasn't really an option. There's a bout 2Gb free now so that should be enough.
    Tuesday, February 5, 2019 11:25 PM
  • Deployment into the slot was succesful and I've dropped the slot containing the old site, reducing the disk usage by a whopping 26Gb. Thanks for your assistance. We will swap out the other site tomorrow.
    Tuesday, February 5, 2019 11:37 PM
  • OK .. should we stop deleting files from the folder then?


    Suwatch

    Tuesday, February 5, 2019 11:41 PM
  • Seem like you have deleted the site (slot) with lots of files - we will stop the removing files process now.   As you know, please don't let it grow unbounded since it is time consuming to delete large folder (with 100k files or more).

    Suwatch

    Tuesday, February 5, 2019 11:55 PM
  • Yes, you can stop deleting the files.

    We'll investigate the root cause with the CMS vendor and make sure it doesn't happen again.

    Thanks!

    Wednesday, February 6, 2019 5:27 AM