![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Archive Failure Topic Summary: Created On: 13-Apr-2005 11:29 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I am currently experiencing problems archiving a project. Each time I archive, I get the following message which appears at least 45 minutes into the process "Input file read failure". I have ensured there are no locks in the database, rebooted the server, looked for locked files on the server, I have also written a script that archives all the modules in the project individually (all modules archived successfully). Note that I am running DOORS 7.0 the size of the last good archive was 2.16Gb and the archive is made up of 550 modules (OK its big but not enormous). Nothing seems to work I always get the same error and no data whatsoever is transferred to the client machine performing the archive. Has anyone out there had a similar problem and if so, what was the cause and how did you solve it.
Thanks in advance for any replies Richard Good Systems tools and doors support ------------------------- Regards, Richard Good |
|
![]() |
|
![]() |
|
Don't know. Try copying the Project and then archiving the copy.
|
|
![]() |
|
![]() |
|
Can you log on at the server and complete the archive?
|
|
![]() |
|
![]() |
|
DOORS support have suggested trying to archive directly on the server, but the bureacracy involved with doing anything other than looking at files on the server is immense, maybe if I request it now I'll be able to do it just before I retire!.
I like the project copy option but am worried that the links will be effected, the project also has attribute dxl/ layout dxl which references other modules using their full names or item numbers (think the traceability stuff also uses this), I'd have to kiss goodbye to all that if we found the copy of the project would archive and wanted to retain it in favour of the corrupt original. Of course deleting the original project and changing the copy names would solve a lot of these problems, think doing this would make me paranoid that I'd broken somthing. I will probably try this option though if only to rule out the project size being a factor. DOORS support have stated that this sort of error can be generated by the winzip technology that underlies the archive process and that there is a limit of 65,535 files for each archive. I do not believe I am any where near this limit and have deleted/ purged a substantial number of modules such that I am sure I have many fewer modules than at the time of the last good archive. On this note it would be interesting to know the archive size of any huge projects out there (are there any of >5GB for instance). Telelogic do not seem to give an absolute limit on maximum project size, does anyone out there have a number for this? I'm also pursuing another option. I'm currently trying to utilise tools written to extricate ourselves from a previous database corruption where computer services had no back up to help us with The tool does the following: -. Creates module archive of all the modules in the project Save all the links to CSV Save the folder hierarchy to file Save the access rights to file Then recreate it all on another server Works well for a small project, just about to try it for the monster, this will of cause stuff up any attribute dxl using item numbers and I will be paranoid that I have forgotten to save somthing but its an interesting exercise, anyone done anything similar? Cheers for any suggestions Richard Good ------------------------- Regards, Richard Good |
|
![]() |
|
![]() |
|
We have also problems with two modules to archive these under DOORS 5.2 .
Both modules have more than 64K files, therefore to archive this module is only possible with rar. I've reported this issue in 10.2003 to Telelogic but DOORS 7 seems to have the same problemes. Anyway, if I need to make a repository (complete archive), I archive the whole DOORS database with RAR. ------------------------- Dirk Plaschke |
|
![]() |
|
![]() |
|
Making some admittedly painfully slow progress on this most irritating of problems, pretty sure it is the 64K files problem. It seems that all modules in the project archive individually, but if you archive them within a project you get the links as well, so the module archives within the project archive are bigger than when you archive a module by itself. Theres no real way of testing which module is causing the problem other than removing one of your biggest and ugliset modules and trying a project archive, putting it back and removing another, trying again etc. Found the problem module on the second attempt. ------------------------- Regards, Richard Good |
|
![]() |
|
![]() |
|
Richard
DOORS 8 will have a mechanism to allow creation of archives with greater than 64k files. Regards Mandy |
|
![]() |
|
![]() |
|
I know this is an old thread, but I too have just hit this problem for the first time.
We use DOORS build 71102. In analysing the DOORS folder(s) on the server, we appear to have over 242,000 files occupying 13GB+, mostly in a folder called v6data. This confuses me rather, as the last time I did a full archive with baselines was four months ago (we've done a few without baselines since) where the dpa file was 1.8GB. I can't believe (even realising that the dpa is zipped) that we've created 180,000 files over the 64k limit in just four months. Has anyone managed to resolve this issue - without upgrading to DOORS 8 ? |
|
![]() |
|
![]() |
|
I don't recall the exact reasons, but DOORS v7.1 build 71102 (unpatched) had serious problem and that upgrading to patch #3 (build 71122) was required. Patch #3 worked well. I also don't recall exactly which future builds created disasterous corruption (patch 9, 10, and 11 I think) and they must be avoided. The patch #12 readme talks about that database corruption.
Sounds like you have only one project in the database? - Louie |
|
![]() |
|
![]() |
|
Hi Louie and thanks for the reply.
We still use client s/w rather than running DOORS on a (CITRIX) server, so no client s/w has been updated since we moved to v7 many moons ago. Although I am aware of newer v7 builds, it is only through these forums, so I suspect 99% of our users think that 71102 is the latest. IMO this makes it a process issue at our end and the need to move to CITRIX and DOORS v8 becomes imperative to avoid problems like this in the future. We have around ten projects in our database but, obviously, I was only trying to archive one of them, so I suppose the 242k files includes all the others as well and is a red herring. Whether we have exceeded the 64k files I therefore don't know, and I'd ahve to understand the purpose of all the files and fodlers on the server to work it out. Alan |
|
![]() |
|
![]() |
|
Don't know the exact details, but I'm fairly confident the following is true about archiving:
[] When browsing the database file structure, first dowse yourself in gasoline and hold a burning torch over your head with your left hand. That will remind you not to change a single thing. [] Excepting some heroic decryption and interpretation of database binary files, you cannot deduce the size of a project by looking at the database file structure, since the module data is stored sorted by UniqueID and not sorted by DOORS project-folder hierarchy. Now you can reasonably guess the size of a module archive since all its files are stored in the same folder, and you can deduce the name of that folder from within DOORS (look for this folder: print "m" (uniqueID(item(fullName(current Module)))) ".mod\n"). Don't think that's useful, but you can do it. [] the archive appears to contain the 'current' and also the 'backup' versions of the files; thus an archive is almost as big as the sum of its database files. Perhaps the difference is compression of files that are almost compressed anyway. Don't really know about a file limit in archiving. - Louie |
|
![]() |
|
![]() |
|
:-)
Following on from an earlier post, I guess my best bet is to call our Telelogic hotline and try and arrange a build 3 update to v7 (if it still exists), so I can get to the point of being able to move the database and then upgrade to v8. |
|
![]() |
|
![]() |
|
We have a similar problem archiving some of our projects.....We get an error basically telling us we ran out of memory. My IT guy has spent several hours on the phone with Telelogic and we have yet to be able to archive. Now we're also trying to archive project that contains ooooo....about 35-40GB of data.
From what I understand, the project is essentially copied when creating an archive,so 35GB becomes 70GB during the archive process.....Well ummmm...Our server only has 50GB dedicated to DOORS, according to my IT guy. Kinda small for a server, but they have other apps running on the same machine. This might not be a problem but according to Telelogic DOORS doesn't support SAN volumes.... Well they are replacing the server 1st quarter of 2008 and the plan is to dedicate much more HD space to DOORS. They better at least, cause our database is about to become much, much bigger over the next year, at least 4-5 times its current size........ ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|
![]() |
Telelogic DOORS
» Administration
»
Archive Failure
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.