locked
Office Document Imaging Multi-Part TIF's corrupted by WHS RRS feed

  • Question

  • I use MS Office Document Imaging to scan all correspondence I need to keep, such as financial statements into Multi-part TIF's.    Each image file contains the documents received for a particular topic, such as a pension plan, in date order.

     

    I then keep these documents organised by year in a folder on WHS - the folder is set to duplicate across drives.

     

    This scheme means that if I receive a new document in the post, I scan it in and then open up the relevant multi-image TIF and paste the scanned page into the end, then save the file.  All of this is done with MS Office Document Imaging.

     

    I find that the save back to the WHS is very slow, and documents are commonly corrupted.  If I try to re-open them with MS Doc Imaging I get a message indicating invalid file format.

     

    The streams utility says that the MS format does not include internal file streams.

     

    I now have to copy the documents to my local PC, edit them there, copy them back, wait a few minutes and then reopen them from the share to see if they are ok.

     

    I hope this provides you enough information to understand whether this is the same data corruption issue seen with other programs.  As I am sure you are aware problems like this severely dent public confidence in WHS.

    Monday, February 4, 2008 1:37 PM

All replies

  • SlasherMCT,

     

    While I am not the expert on all things WHS (there are better out there Ken etc.) I am fairly knowledgable over the WHS data corruption issue (having had to replace much lost data). I can tell you positively that the file types that can have the problem is significantly more widespread that MS currently acknowledges.

     

    It has been my experience that any file that is in a shared folder that has the potential to be updated while working with it remotely can be corrupted. It is not limited to MS's current known list.

     

    I have not experienced the above issue is the files are stored in a drive attached to the WHS that is not in the drive pool. I am not an MS technical representative but this would lead me to believe the problem is how the Drive Extender technology is being used within WHS. I for one am suprised of the extent of the corruption issue but one never knows what will happen when software enters the wilds of consumer land.

     

    Again I want to state that I am not a representative of MS or am an WHS expert, this is just what I have seen with my own HP MSS when testing out different file types and pushing the limits of my WHS server. If I want to use a file it is first copied to the local machine, used / edited, then copied back to the WHS for storage, this seems to eliminate corruption errors.

     

    Files I have tested that have corrupted when editing in a shared folder

     

    .mp3

    .mp4

    .mkv

    .doc(x)

    .ppt(x)

    .xls(x)

    .mny

    .jpg

    .gif

    .tif

    .avi

    .mdb

    Monday, February 4, 2008 2:26 PM
  •  SlasherMCT wrote:

    I use MS Office Document Imaging to scan all correspondence I need to keep, such as financial statements into Multi-part TIF's.    Each image file contains the documents received for a particular topic, such as a pension plan, in date order.

     

    I then keep these documents organised by year in a folder on WHS - the folder is set to duplicate across drives.

     

    This scheme means that if I receive a new document in the post, I scan it in and then open up the relevant multi-image TIF and paste the scanned page into the end, then save the file.  All of this is done with MS Office Document Imaging.

     

    I find that the save back to the WHS is very slow, and documents are commonly corrupted.  If I try to re-open them with MS Doc Imaging I get a message indicating invalid file format.

     

    The streams utility says that the MS format does not include internal file streams.

     

    I now have to copy the documents to my local PC, edit them there, copy them back, wait a few minutes and then reopen them from the share to see if they are ok.

     

    I hope this provides you enough information to understand whether this is the same data corruption issue seen with other programs.  As I am sure you are aware problems like this severely dent public confidence in WHS.



    While Pansito is correct on his overall statement the key factor that plays into this is that updating/writing is possible so long as the program is using \\servername\sharename over the network.

    This will ensure the files are not corrupt.

    However there are files that can be corrupted even if you use this method and this is due to the exclusive lock that is required by the program.

    IE: PST (outlook.pst etc)

    These files will not allow the DE to access them because they are locked hence this can cause corruption.

    I don't believe mdi's or tiff's would cause this error but then again I am not 100% sure how you are accessing these files. it is possible to lock a tiff execulsively so I cannot rule out that this is not the case and could very well happen.

    MSFT continues to hold strong that this flaw will be resovled in the up coming weeks. But don't hold your breathe.
    Monday, February 4, 2008 3:12 PM
  • JonTheTech

     

    I access the files using \\servername\sharename I also map the directories as drives. Corruption on both accounts, so writing / updating is not possbile if you wish to ensure no data corruption. You are playing russian roulette otherwise.

     

    I do hope the issue is resolved soon as I want to use the device as intended and not as a really expensive backup device.

     

    Panson

     

    Monday, February 4, 2008 3:32 PM
  • I accessed the files through \\homeserver\sharename on the client pc.  I always use the shares as documented even if I am moving files around using the home server itself.  No-one else on my network was accessing the files at the same time, (everyone was out of the house)

     

    I think you are implying that it may be a problem with the program not getting a lock on the file.  I find this unlikely as any program writing to the file must have it open for write.  I suppose there is a possibility that MS Office Imaging could open and close the file for each page of the multi part tiff, but then if DEMigrator got in during the update, surely then next write open by imaging would fail.

     

    In fact I have seen a message from imaging when I have been reopened the files after copying them onto the share( to verify they aren't corrupted), to the effect that I can only get read only access because something else is accessing the file - presumably the migrator.

     

    This is basic stuff & I amazed that the WHS team didn't pick it up in their testing.

    Monday, February 4, 2008 3:49 PM
  • Regarding Panson's statement that file types other than those specifically listed in KB946676 are affected, yes, Microsoft acknowledges in the article that other file types and programs may also be affected. (Go read the article if you haven't already.)

    I don't think Jon is correct about exclusive locks. I think it's random access writes that causes the problem. But I don't have any specific information from the WHS team on that. Just as I don't have any information I can share on when the issue will be fixed, other than as soon as possible consonant with properly testing the fix to make sure there are no unintended consequences. I'm told it's the team's only priority at this time.
    Monday, February 4, 2008 6:12 PM
    Moderator