locked
Server Backup skips files with a long path RRS feed

  • Question

  • It looks like they fixed the share file length bug in PP1.  For example: \\Server\Music\<Realy Long File Name over 260 characters>.mp3 will now work and not give you errors later.  But it looks like they didn't test this fix in combination with the Server Backup feature they added in PP1.

    https://connect.microsoft.com/WindowsHomeServer/feedback/ViewFeedback.aspx?FeedbackID=350475

     

    What I don't understand is why they closed the bug with "Closed (By Design)".  I highly doubt it was by design since it that would mean they meant it to not work with long file names.  I would have thought it would have been marked is some way to show they will release a fix later.

     

    I just hope they don't wait until PP2 to fix this issue, because if you start having longer file names since the corruption bug appears to be gone and long files are supported, you can't back them up from the server.  I can understand that they might not want to fix it right now in PP1, especially if it is pre-corruption bug fix code.  It might require a lengthy reworking of the code to work (due to .net path limitations), but I do hope they fix it very quickly as anything related to data integrity (backup are related) should have very high priority.

    Friday, June 13, 2008 6:29 PM

Answers

  • The bug should have been marked 'postponed' - I will bring this up with the triage team. 

     

    We don't have the cycles to fix this issue with Server Data Backup not supporting long filenames right now.   You are correct - it is due to .Net path limitations.  We fixed the Drive Extender migrator code to deal the with .Net limitation.

     

     

    Friday, June 13, 2008 9:40 PM

All replies

  • Stephen, the correction to allow long file names to work is mentioned in the release notes.

    As for the other, please post a bug report on Connect, with talq logs from your server.
    Friday, June 13, 2008 8:05 PM
    Moderator
  • The bug should have been marked 'postponed' - I will bring this up with the triage team. 

     

    We don't have the cycles to fix this issue with Server Data Backup not supporting long filenames right now.   You are correct - it is due to .Net path limitations.  We fixed the Drive Extender migrator code to deal the with .Net limitation.

     

     

    Friday, June 13, 2008 9:40 PM
  • Thanks for the quick reply.  I'm glad you'll be bringing it up with the triage team.  I understand it can be difficult to determine what should or should not be worked on when it gets close to a release date for a product/update.  While I would like to have it fixed as soon as possible, I definetly do not want PP1 to be postponed because of it.

     

    Thanks

     

    P.S.  Any chance the .Net team will expand/eliminate the 260 character limitation?  I've ran into it myself just using Powershell and getting a directory listing (it just doesn't show some files).

     

    Saturday, June 14, 2008 3:11 AM
  • Stephen, if they use the functionality built in to the .Net Framework, there's no way around this limit. That's why you see the same problem in PowerShell. Microsoft will have to write their own string handlers to allow for long file names in the server backup, and it's obviously not possible to use the handlers built for DE for that purpose.
    Saturday, June 14, 2008 1:33 PM
    Moderator
  • Adding to this Server Backup used to fail when it would reach a file of this length or greater. Server back now skips files with long filenames so that everything else is backed up. The rest follows as todd stated.

     

     T. Headrick wrote:

    The bug should have been marked 'postponed' - I will bring this up with the triage team. 

     

    We don't have the cycles to fix this issue with Server Data Backup not supporting long filenames right now.   You are correct - it is due to .Net path limitations.  We fixed the Drive Extender migrator code to deal the with .Net limitation.

     

     

    Thursday, June 19, 2008 9:49 PM
  • I confirm, I discovered recently the same bug... the WHS now works fine with long filenames, but the server back up doesn't.
    You have the same effect with if you have broken handles (
    orphan shadows) and WHS tries to store them under D:\folders\{1618D36B-F4E7-4360-B070-A32070519DC9} folder... here also the long filenames are not supported. I reported this also already on Connect and the error and this error was also closed "by design"... cf: https://connect.microsoft.com/WindowsHomeServer/feedback/ViewFeedback.aspx?FeedbackID=352332 - here what MS answered "At this point in time, the behavior you are experencing is by design and so we are closing this feedback item.

    To work around this you will need to change the file path on have less characters. It is recommended that you change the path from the top down."

    I does not motivate me to report any other errors as it seems that MS is not interested in errors they don't like!

    I wanted to send the logs but
    I was not able to provide CAB number as TALQ Log could not be generated. I deinstalled and reinstalled the Toolkit, but no chance.

    Saturday, June 28, 2008 7:25 AM