Click for MacWindows
Last updated June 11, 2001
A number of readers have reported problems of Quark Xpress file corruption when saving files to an AFP server. The problem was first reported with PC MacLAN, but has since been reported occurring with all AFP servers, including Windows NT SFM, AppleShare IP 6, MacServerIP, and Linux running Netatalk. The problem seems to be cause by the unusual way Quark Xpress saves files.
We have one report on how to avoid the problem and another suggests a workaround.
We also have some reports of the problem and fix for MacServerIP on our AFP Server for NT special report page.
January 17, 2001
I have been implemented PC MacLAN for NT on my network. We run predominately Macs on the network. The main program used here is Quark. The reason for implementing PC Mac LAN was to take advantage of its AppleShare IP file sharing. The week after I implemented it was chaotic with files corrupting everywhere (Quark files). You can't even do a save as over the network, this causes an error.
The version of PC Mac LAN is the NT 4.2 version. I am running Windows NT 4.0 with Service Pack 5.
Miramar responds: how to avoid the problem
January 29, 2001
We have seen this problem in the past and have worked with Quark to come up with a work around. Below is a paragraph copied directly out of my personal notes.4-25-00. Spoke to Scott Henry at Quark. He is a QA engineer who deals mostly with the PC side but works with the Mac stuff as well. He says they saw this problem in the past on Novel AFP servers where the rights of the folder were read/write/modify but not create. If the user double clicks on the Quark file on the server the temp files have to be created on the server at the location of the Quark file being opened. If they cannot be created then there are problems.
If quark is opened and File Open is used, the temp files are then created at the location the OS stipulates. This prevents the Quark temp files from being written across the network to the AFP volume and should help the situation.
Quark recommends 8.3 naming convention and simple server and path names when using quark files cross platform because they maintain a usage profile in the quark file that is supposed to keep track of all graphics and external files. This can get screwed up pretty easy by the cross-platform UNC and file naming differences of PC's and Mac's.
Because of the way Quark handles its temp files, it is a bad idea to open a Quark file from any AFP Server. The best thing to do is to copy the Quark file to the local machine, open it, edit it, and close it; then copy it back to the AFP Server.
Miramar Systems, Inc.
January 29, 2001
When we transfer QuarkXPress files via sneakernet from Mac to PC and back again, very often the files are corrupted even if they haven't been opened on the PC. Sometimes they can be rescued by changing the creator/file type flags with a utility like FileBuddy. But more often than not they have been irrecoverably damaged.
It happens with QXP 3.3 and 4.1 files. Macs running OS 9.1 and PC Windows 98. Yet transferring the same files via the same method to other PC's has caused no problems in the past.
January 31, 2001
Bryce Steiner doesn't believe opening the files on any AFP Server, as previously suggested, causes the problem:
I've been running Win 2000 server for nearly 2 years now and have not had this problem with Quark on the Mac at all. I have those same file permissions at the top of the article. I don't think it effects all AFP servers.
January 31, 2001
Mike Hughes saw the problem on a Windows NT Server running Services for Mac, but not with ExtremeZ-IP running:
With PC's running NT 4.0 connecting to an NT 4.0 server using standard [SFM} NT file sharing, we would see 1-2 Quark files per day corrupt. Markztools was usually able to repair the files.
We have since installed over 100 new Macs, and during testing between Extreme Z-IP and Thursby Systems Dave Client, we saw a pattern develop. The Macintosh computers that were using Dave still saw the same file corruption.
The Macintosh computers that were using ExtremeZ-IP saw no file corruption. Given that the ExtremeZ-IP software produced better benchmarks and did not cause file corruption, we have setup all users to connect Via ExtremeZ-IP. We see maybe 1 file every 2-3 weeks that corrupts, and this is usually caused by a users that has crashed will saving.
June 5, 2001 -- A MacWindows source relayed some information about why Quark Xpress corrupts on AFP (AppleShare -compatible) network volumes, as relayed to him by Quark engineers:
They told me about the way Quark opens its temporary swap file at the location of the source file. They make all sorts of weird calls to this file, get and putting data, etc. If any little thing goes wrong with the network communication or if any call is not supported properly by the AFP server... Instant file corruption. He told me that he had seen this corruption on all sorts of AFP servers and that the best thing to do was to copy the file to the local machine, edit it, save it and copy it back to the server.
I've noticed that all the newer Adobe applications will not allow network volumes (mapped or not) to be used for swap files... Adobe is doing it right.
Workaround and further explanation.
June 11, 2001
I was having problems with corruption on an AppleShare IP 6.2 server sometime back, a newspaper publishing client. I went back and forth and back and forth with Quark about the issue. The last time we had spoke (and again, this is some time back, maybe a year) the work around discussed was this:
When you double-click a Quark file in the Finder, Quark opens it and attempts to create the temp files in the same directory. So if the file was on an AFP server, that's were they go. If, on the other hand, you do a File:Open from inside Quark, and open the file from the AFP server, Quark does the right thing and puts the temps locally, not causing problems.
I did not write Xpress, but this is my understanding of what is going on. Quark doesn't write temp FILES, but instead creates temp CHUNKS within the file space of the open file. The Mac OS's file manager will allow this. When you actually save a file, Quark picks and chooses which chunks to use and then passes that info to the File Manager, to create a "file" out of. The "fragments", since they were never really "used", will eventually be overwritten, albeit creating a bit of fragmentation on your drive. If you do this to an AFP server, which by default does NOT act like the Mac OS File Manager, especially behind the scenes, the server ends up with a whole bunch of unclaimed file fragments that it MUST account for causing directory corruption, mostly because this is done in memory and not directly on the drive.
When a user double-clicks on a file located on an AFP server, Quark has no idea that it is working from a mounted volume (which I don't understand, because it only seems rational that the Mac OS File Manager would allow an app to determine if a volume was a mounted network volume, but I am not a programmer--IANAP) so it treats it as though the file is local. On the other hand, if the user explicitly opens the file from within Quark's Open dialog box, Quark is able to determine that the volume is a mounted network share and treat the file differently, mostly because of how programs handle Open/Save dialog operations (again, IANAP, but apps must have to do more work if they Open/Save on their own, versus if they are sent an open event from the Finder).
So, for what its worth, that may help. This is a known Quark issue. It has been for some time, and until Quark sees fit to fix it...well we wait. Personally, they have known about it for nearly two years (from my personal experience), so I wouldn't hold your breath. Maybe Quark 5. Ha.
And the reason that it affects different servers more or less severely depends on the back-end of the server--how does it handle all these file fragments that never get "cleaned up".
June 11, 2001
On June 8, Macintouch reported that the Quark corruption problem also occurs on Linux servers running Netatalk.