Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com From: Franz Haeuslschmid Subject: Re: Cygwin xfig eps problem Date: Tue, 04 Oct 2005 10:56:13 +0200 Lines: 148 Message-ID: References: <78ba8be805093011245fd43c27 AT mail DOT gmail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.5-b22 (cucumber, windows-nt) X-IsSubscribed: yes Mike, I think I've found the reason for XFig's strange behaviour. Let me first reply to your message. m shi writes: [...] > From what I've read, there do seem to be a couple of minor > variations on a theme here: > > 1. Your post does not mention being able to successfully (with > preview) import the first eps file that you try in a given xfig > session. Are you able to? I was initially not able to, until I > changed my system temp path (BOTH windows and cygwin) to a > directory without spaces in the complete path (instead of > windows' ridiculous default location in "\Documents/ and/ > Settings" Yes, I am able to import at least once (as XFig is running) an EPS file. And I didn't need to change my path. Did you try to mount `$TEMP' (the MS Windows environment variable) on `/tmp'? > 2. The other post you mention describes gs from the command > line not liking a /tmp path for -sOutputfile. I have tried from > the command line, and my gs outputs fine to /tmp (which is the > manner in which xfig appears to refer to the file). I have > tried the scripts proposed by Igor in that thread, (with both > cygwin's gs and gswin32c) and they do not change the behavior I > am seeing. That how I tried to originally solve my problem. Deeper in that thread, it is reported that XFig fails when importing an EPS as it cannot read the preview. I just wanted to point out this thread to show, that out problem is already known. However, at that point of time, the original poster could not supply enough information to extract the problem. > I think it does have something to do with file permissions - > perhaps the gs spawned by xfig has a user that our systems do > not know anything about (but which exists by default on *nix > systems), and therefore the .pix file is somehow invalid. Are > you using NTFS for the partition containing your /tmp > directory? Perhaps also it only affects installations using > NTFS since other windows filesystems don't care about security > so much, and perhaps that is why not everyone sees the same > behavior? (Just speculating here.) I use XP Home, so I do not > have a "Security" tab unless I use safe mode - maybe I'll try > that now to see if I can get any more information. It has indeed to do with file permissions, however `gs' is innocent. XFig may be solely responsible for leaving a file without permissions. On the other hand, it may be up to the functions `fclose' and `unlink'. Let's see how this comes. As I'm curious by nature, I decided to inspect XFig's sources. The function `bitmap_from_gs' in file `f_readeps.c' has the task to create the command for executing `gs' with appropriate arguments for generating the preview and finally to call it. It then reads the preview from the temporary file for further processing. The following excerpt should show the relevant parts of the function causing the trouble: /* Read bitmap from gs, return True if success */ Boolean bitmap_from_gs(file, filetype, pic, urx, llx, ury, lly, pdf_flag) FILE *file; int filetype; F_pic *pic; int urx, llx, ury, lly; int pdf_flag; { char buf[300]; FILE *tmpfp, *pixfile, *gsfile; char *psnam, *driver; int status, wid, ht, nbitmap; char tmpfile[PATH_MAX], pixnam[PATH_MAX], errnam[PATH_MAX], gscom[2 * PATH_MAX]; /* ... */ /* The file name for the file holding the temporary preview is constructed. The name is stored into `pixnam'. */ /* ... */ /* The gs command is prepared. The resulting preview bitmap can then be read from the file referred to by `pixnam'. The command is stored into `gsfile'. */ status = pclose(gsfile); if (filetype == 1) unlink(tmpfile); /* error return from ghostscript, look in error file */ if (status != 0 || (pixfile = fopen(pixnam, "rb")) == NULL) { /* ... */ /* The message is known. The second preview is written to the same file, for which no permission is set at that moment. */ file_msg("Could not parse %s file with ghostscript: %s", pdf_flag ? "PDF" : "EPS", file); /* ... */ } /* ... */ if (tool_cells <= 2 || appres.monochrome) { /* For our problem, only the alternative branch is relevant. */ } else { FILE *pcxfile; /* ... */ pcxfile = open_picfile(pixnam, &filtyp, PIPEOK, tmpfile); status = _read_pcx(pcxfile, pic); /* The following line was inserted by me. XFig then imports EPS as expected! */ fclose(pcxfile); /* ... */ } fclose(pixfile); unlink(pixnam); /* When you use a debugger and passed this line for the first preview, you'll see that the file `pixnam' has no file permissions set using the file properties dialog of Windows Explorer. */ unlink(errnam); return True; /* Success */ } The bottom line is, that two `FILE' objects named `pcxfile' and `pixfile' are created based on the same temporary file referred to by `pixnam'. The function `fclose' is used to close a file and it is _only_ called for `pixfile'. The function `unlink' is used to remove the temporary preview. At the moment when `unlink' is called for `pixnam', there still exists a file object (pcxfile), which hasn't been closed yet. I'll propose a patch that adds that line for closing `pcxfile'. On the other hand, I'm wondering why `unlink' doesn't remove the file as it should do. Regards, Franz. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/