import eps from read only folder

[tatankam]

When I import an eps file from a readonly folder I obtain :
I have windows XP.

have a folder "pippo" where I have read permission.

If I choose File->Import and I select an eps file from that folder I obtain:
"Access is denied.
Access is denied.
Access is denied.
Access is denied.
Unable to open command line file _.at"

because it isn't able to create .at file.

The problem is because ps2pdf use that temporary directory.

If I modify run_command.py adding the line:
os.chdir(tempfile.gettempdir())

after the line

msg = None

and it solves the problem as suggested by "sas"
http://www.inkscapeforum.com/viewtopic.php?f=5&t=797&start=25#p19657

Thanks.

[sas (sas-sas)]

Here's a patch.

The problem was that (in Windows, at least) ps2pdf tries to write a temporary file to the current directory, which may not be writeable. The fix is to (attempt to) change directory to the temp directory before running the command.

This patch also includes some minor changes to reflect the fact that the file that run_command.py produces can be a PDF file (whereas it was originally only used to produce SVG files).

I've only tested this patch on Windows XP, so it would be useful if someone could test on OS X or Linux (opening or importing .ps or .eps files, or other formats such as .fig and .cdr that use this script).

[sas (sas-sas)]

To facilitate testing, here's the modified run_command.py, which should replace the existing run_command.py in Inkscape's extensions directory.

To be clear: the tests are only to establish that the changes don't break import/open for the affected formats - the quality of imports will be unchanged.

[su_v (suv-lp)]

Inkscape 0.47+devel r9020 on OS X 10.5.8

I tried opening *.eps, *.plt, *.cdr and *.wmf test files (all these input extensions depend on 'run_command.py') with your patched version and did not discover any failures due to cd'ing to the 'tempfile' directory.

OTOH I could not reproduce the error when importing an EPS file from a read-only directory:

$ ll tmp/imports/ | grep read-only
dr-xr-xr-x 3 suv staff 102 Jan 26 14:41 read-only/
$ ll tmp/imports/read-only/
total 24
-rw-r--r--@ 1 suv staff 9262 Jan 26 14:41 190424-test.eps
$ gs --version
8.70

AFAICT ps2pdf on osx (installed via MacPorts) creates the temp PDF file in the default user temp directory (same location as is returned by 'getconf DARWIN_USER_TEMP_DIR') anyway.

[sas (sas-sas)]

I think this can be added to bzr now, since it's a fairly trivial change and no problems have been found. (I would add it myself, but my commit access is for SVN, which is not much good now.)

[su_v (suv-lp)]

I am puzzled by bug #514949 “after opening .eps file, the temporary file is not deleted”:

«running Windows XP, Inkscape 0.47 r22583 (Nov 21 2009)
- when I open an .eps file, it loads normally and it creates a temporary file as normal, in the directory C:\Documents and Settings\Alvin Penner\Local Settings\Temp\, as expected.»

It seems that ps2pdf does *not* create the temp files in the current directory of the EPS file, at least not on every Inkscape Windows installation.

[sas (sas-sas)]

@~suv:

This is a little confusing, because there are several different temporary files involved.

The ones that are causing this particular bug are produced by ps2pdf, but only on Windows. They are a way of working around the awkward batch language that Windows uses. These files are called _.at and _.at2.

Then there is the temporary PDF file that run_command.py produces. This is copied to stdout and then deleted. These files have names like tmphjc4um.svg (on Windows, at least).

Then there is the temporary PDF file that Inkscape's helper-extension system produces. This is produced because the next extension (the internal PDF-to-SVG one) needs a file to work on. These files have names like ink_ext_XXXXXX.svgIUS66U and for some reason are not deleted.

[Alvin Penner (apenner)]

tested on Windows XP and committed,
thanks again, sas!