locked
Folder duplication Failing! RRS feed

  • Question

  • I get an alert that folder duplication for my personal folder is failing.  It says that there isn't enough free space to duplicate this info.  It is only 1.5 gigs and I know that I have more free space than that.  I even added about 20gigs of MP3's to be duplicated after this message popped up, and it did not have a problem, only the one folder.

    Sunday, February 25, 2007 12:18 AM

Answers

  • cweb, please add info to and vote on this bug on Connect if you haven't already; there are a few of us having this problem. The longest total pathname in my duplication-failing share is about 140 characters.

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

    Sunday, February 25, 2007 7:56 AM
  • Folder Duplication requires enough free space on your hard drives such that 2 copies of each Shared Folder that has duplication enabled can be stored on 2 separate drives.

    So let's say you have an 80 GB hard drive and a 120 GB hard drive.   Let's assume that the 80 GB hard drive is the first (or primary) hard drive so 10 GB is taken up by the operating system in Beta 2 so you only have 70 GB left for data.    So, even though you have 190 GB of free storage for storing your data, you will only have a little less than 70 GB for shared folders with duplication enabled.   I use the phrase 'a little less' since that first data drive is also used as a storage place to keep track of which hard drive all of the shared folders are stored and if duplication is enabled it keeps track of where each of the 2 copies are stored.

    Without knowing more about your setup - it is hard to answer your specific question.  Try turning off duplication on that shared folder and then turning it back on.

    Please submit a bug via Connect with your TALQ logs if you think you have found a bug.

    Monday, February 26, 2007 4:20 PM

All replies

  • Duplication happens slowly, not instantaneously. So your second folder might not report problems until a few minutes later (not suggesting that it *will* be having problems, but just FYI).

    So both your drives have atleast 1.5 GB free amd still the console says that duplication failing due to lack of space? Just a thought - is any of your file paths longer than 256 characters in length? There is a limitation that duplication fails for file paths > 256 characters in length. Just wondering whether the same issue is maniputaintg itself with a wrong error message.

    Sunday, February 25, 2007 12:28 AM
    Moderator
  • cweb, please add info to and vote on this bug on Connect if you haven't already; there are a few of us having this problem. The longest total pathname in my duplication-failing share is about 140 characters.

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

    Sunday, February 25, 2007 7:56 AM
  • do you know of any software to do the character count for you?

    I have tried to delete all the files that looked semi long in total path characters, and still got the same problem, although I didn't do a true count of the characters, but never had a problem before.
    I also deleted the folder from the share, and created a new share and copied files over again.  Still have the same problem.  So there must be some file that is throwing it off.


    I have voted and added info on connect.
    Sunday, February 25, 2007 10:57 AM
  • For the counting, I ran this at a command prompt:

    dir /a /s /b \\server\sharename > serverlist.txt

    And then opened the serverlist.txt file it created in Crimson Editor (any decent text editor will do). From there it was fairly easy to scroll around to find the longest lines and count how long one was.

    Sunday, February 25, 2007 1:06 PM
  • I've been looking through the log files on the server.

    What I've seen (in q_de.log) is that, in the process of duplication, files are being renamed. (It adds some characters to the file extensions)Sometimes the file extension that it tries to rename to already exists, which results in an error. I'm guessing that the message we get through the WHS tray icon about not enough disk space is just a generic way to say something went wrong during duplication...

    Sunday, February 25, 2007 8:57 PM
  • so what your saying is that maybe if we have 2 files that are similarly named, then it could rename them to the same thing?

    I counted, and only have a file as long as 103 characters total path.
    Sunday, February 25, 2007 10:01 PM
  • Folder Duplication requires enough free space on your hard drives such that 2 copies of each Shared Folder that has duplication enabled can be stored on 2 separate drives.

    So let's say you have an 80 GB hard drive and a 120 GB hard drive.   Let's assume that the 80 GB hard drive is the first (or primary) hard drive so 10 GB is taken up by the operating system in Beta 2 so you only have 70 GB left for data.    So, even though you have 190 GB of free storage for storing your data, you will only have a little less than 70 GB for shared folders with duplication enabled.   I use the phrase 'a little less' since that first data drive is also used as a storage place to keep track of which hard drive all of the shared folders are stored and if duplication is enabled it keeps track of where each of the 2 copies are stored.

    Without knowing more about your setup - it is hard to answer your specific question.  Try turning off duplication on that shared folder and then turning it back on.

    Please submit a bug via Connect with your TALQ logs if you think you have found a bug.

    Monday, February 26, 2007 4:20 PM
  • Re. the renaming: what *seems* to happen (from reading the logfile) is: there is a file called photo.jpg, on which WHS tries to do a rename to something like photo.jpg_0123. I'm not sure about the process, because in Explorer I can see that now both files exist. A little later WHS again starts a rename operation of photo.jpg, f.i. to photo.jpg_0262. After some time, and only sometimes, it is trying to do a rename again, but now to photo.jpg_0123, which already exists. The log the (correctly) shows: "Cannot create a file when that file already exists".

    Monday, February 26, 2007 8:26 PM
  •  Tuttle wrote:

    cweb, please add info to and vote on this bug on Connect if you haven't already; there are a few of us having this problem. The longest total pathname in my duplication-failing share is about 140 characters.

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

    I'm marking this as answered since this is a known bug.

    Thursday, March 1, 2007 8:13 PM
    Moderator
  • When submitting a bug with my connect handle, do I enter "0000000" or "handle0000000" into the TalQ tool? I want to get it right incase they give out free copies to active testers like they did with vista.
    Saturday, March 3, 2007 8:24 PM
  • In Connect, click on "Manage Your Connect Profile" (bottom left corner), then "Personal Information". That's your handle.

    There's a field in the bug report form for you to paste the CAB number that TalQ gives you anyway, and I'm pretty sure that's the best way for the beta folks to match things up. Tagging the upload with your handle just makes it possible to match things up if you make a typo in the CAB number.

    Sunday, March 4, 2007 2:22 AM