Troubleshooting Export Error Code 18
Filed under:
Software Virtualization Solution
Troubleshooting
Submitted by bsuggs on 5 December, 2006 - 11:09
Have you ever spent a huge amount of time on a layer to tweak it just right but when you go to export it you get the dreaded error code 18?
You think to yourself, it launches fine why won't it export?
Well, here's a tip that will help you keep your sanity.
Description:
Error Code 18: 18--ZE_OPEN // could not open a specified file to read.
Possible causes:
- The file can be in use. In this situation, make sure that there is not an open process holding the file open.
- You do not have permission to read the file.
Finding the file with the problem:
- When you are exporting your layer and you receive the error do not click OK! Leave it.
- Go to where the .vsa file is being created and rename it to .zip. This prevents you from losing the export when you click OK on the error.
- You can now safely click OK to the error code 18.
- Open the zip file and find where the export process stopped. You can compare this to the folders located on your redirection point. (Default: c:\fslrdr)
This should give you an idea of what file is causing the issue. Once you determine the file make sure it has the proper permission and make sure it's not in use.
Editor's Note
The most common reason for error 18 during an export is that a file in the source layer is held open by a running process. This can usually be cleared easily by rebooting and trying the Export again. When that fails, this tip can help you zero in on the offending file.
(9 votes)
Examples
FYI...
We saw the permissions issues with fresh install of the following applications.
Adobe CreativeSuite CS2
Adobe Illustrator CS2
Adobe Photoshop CS2
Files:
Hope this helps!
Issue in user section of writable sub-layer?
If you find that the problem causing Error Code 18 is in the user files of the writable sub-layer and you don't really need those files in your archive (vsa) file, you can use Smaller VSA to export your layer instead and you should no longer get the error.
This is not just a theory, I've tried it. It works.
My last run-in with this
My last run-in wih this error was on an application called Rational Application Developer from IBM.
The reason for this error was the folders in RAD exceeded the 255 Character Length.
I got help from Carlos at Altiris on this one and he told me he was also having this problem on Webshpere Studio Application Developer and this is a Common problem on IBM products. Not even Windows can recognize them properly. BUT Java, which RAD and WSAD are, can make speicific calls to those DEEP Paths.
Good example for Smaller VSA
As I sit next to Carlos, I asked him to try SmallerVSA to export his layer for Rational Application Developer in order to test it. It exported without an issue. I don't know if he shared the results of this experiment with you or not.
Since those folders are in the user specific directories, you just need to perform a reset after import and you should be good to go.
Great....I will Give it a shot
Ok I will give that one a shot sounds like a winner
how does it work? does it
how does it work? does it ignore the writable part of the layer and just write down the protected sublayer? if so, thats exactly what i don't want. i need the writable part to share settings of my IRAD.
i get different errors as i export the layer.
at first there was error code 3 and the name of the file that had a too long path. i created a zip file using 7zip and deleted the original folder in safe mode of windows.
after that, i restarted the export. now, i get this error code 18 and no more filename.
using smaller vsa did not work for me.
it actually created a vsa package but as i said. i need those files of the writable part.
It works
SmallerVSA works with the layer meta-data. It temporarily changes the layer so it has an empty writable sub-layer, exports the layer, then changes all the meta-date back to its original settings. This way, even though it is empty in the vsa, the wirtable sub-layer on the machine it comes from remains intact.
The does not fix ever export error for SVS, it only helps with some common ones. Many of the export layer errors are caused due to limitations of the compression library SVS uses. In the next major release, the compression library is being replaced with a more robust one. Most of today’s export woes will no longer happen.
As for files in the writable sub-layer, the writable sub-layer is deleted if you ever reset the layer, so if there are files you want to not lose at reset, copy them into the read-only sub-layer.
I am having trouble with long filenames also
Hello,
I am trying to export a PHP editor, Zend. I get error code 18. After reading the forums I copied the folder, F in this case, to a separate location - copied fine. The error showed up upon deleting the copied folder - Name too long for recycle bin.
I have successfully zipped the Zend folder (F) with 7zip.
I seems that the compression software used by Altiris
won't work with very long file names.
What work arounds are available?
Could I zip the folder separately with 7zip and export a small set of files inplace of the real thing, then import and unzip the folder to the F drive or are there registry files that need to be done also?
I also tried smallerVSA, it reported that it exported but I watched stop at the same place and then erase the temp file it was building.
the trial version of the editor is at Zend.com. It's Zend Studio for Eclipse:
http://www.zend.com/en/products/studio/downloads
incase any one wants try export the app and see what I'm refering to.
thanks
meads
SVS has the same
SVS has the same restrictions as windows does, if the recycle bin can't hold the file SVS shouldn't be expected to as well. You'll have to shorten the install path.
We test for 260 characters long for both file name and path combined (this would include all subfiles and folders) which is what Microsoft has as the limit for windows as well.
If you think it's flat out a problem with SVS create an empty layer and try exporting that, unless you have changed the redirect area path to something that's deep into the system (instead of the default C:\FSLRDR) that should work fine.
Is there a work around?
I don't think there is a problem with SVS. I would however like to have a workaround to the problem. Since 7zip does work on the files and the editor does function just fine, there can't be a Windows limit or problem with the length of the file names. Also other places in the forum comment that the Java Environment has extremely long file names.
Could one use 7zip to compact the files then have the layer archived?
thanks,
meads
Not really because SVS adds
Not really because SVS adds files to the VSA (which is just a zip) that's needed upon import for registry stuff (for both SVS and the app in the layer). I guess you could try to do all that manually but I don't know if it's worth the time or not especially considering you'd have to do the same for import since I doubt that will work if Export doesn't.
I found out another way to determine the file that's the problem
Add a dword value named "Flags" in your registry:
HKLM\System\Altiris\SVS\
Set it to 1
Now open your SVS admin and select "Details" in the view menu.
Now you can see the sublayer info.
You see that it's referring to corresponding folders in your fslrdr.
Open your fslrdr and make a copy of the folder belonging to the problem app to a different location.
It will fail on the file that's causing the problem and display the filename.
Good tip
Using smaller SVS is again a extra step that needs to be done when you get this error.
To keep things simpler, it is better to find a solution in the original SVS to get over it.
K00tje was giving a good tip, but this is also a extra step in the process. Still I prefer the solutions that k00tje gave.
Regards
Erik
www.svs4u.nl
Display layerInfo: use SVS Multitool
Starfox's SVS MultiTool already has a tweak to do this.
Using built in zip
I used your tip to find the folders for the application, but no error showed up when I copied the folder.
So instead I right-clicked => Send to => Compressed folder. And it instantly complained about a long filename and unsupported signs in the filename.
It was a chinese help-file and after removal, it worked as a charm.
Different Language Files
I've seen this once or twice with various applications too. I typically see the problems with the ones whose names can not be put into English characters in Explorer (typically these files will have the open square/box shaped character in place of letters).
I've found that if I locate the folder the application is in and Shift+Delete those files (I like to bypass the recycle bin on things I KNOW I want to delete) that it tends to clear up this error.
I don't understand why those things are passed around or put onto a system if the language isn't going to be compatible with that/those of the system (lazy/sloppy programming IMHO) but they are a real pain.
Thanks for clarifying error 18
You saved me a lot of time!