Re: generated filenames too long
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Andre Poenitz wrote:
>>
>>> On Wed, Jun 15, 2005 at 09:10:48AM +0200, Stefan Kostner wrote:
That's a good point, but still I think that skipping the full path and
keeping the filename only would be a good option.
>>>
>>> This is not sufficient if you have files of the same name in different
>>> directories...
>>
> | Well actually it is, because the code is something like:
>>
> | string const make_tempfilename(string const & filename)
> | {
> | static int counter;
> | return convert(counter++) + mangled(filename);
> | }
>
> I dont' tlike that temp files are made anonymous like this.
We had that discussion some time ago when I worked on the temp dir stuff. We
came to the conclusion that we want the mangled path because one can
identify the file. I think the reasons are still valid, and if people
create long paths that are problematic in dvips they are likely to get
problems in other programs as well.
What we do in 1.4 is to write only the filename (1_home_...) to the .tex
file and not the whole path (/tmp/lyx_tmpdir...), because all files are in
one directory. If that path is still too long, the original path will be
too long, too.
Georg
Re: generated filenames too long
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>
>> On Wed, Jun 15, 2005 at 09:10:48AM +0200, Stefan Kostner wrote:
>>> That's a good point, but still I think that skipping the full path and
>>> keeping the filename only would be a good option.
>>
>> This is not sufficient if you have files of the same name in different
>> directories...
>
| Well actually it is, because the code is something like:
>
| string const make_tempfilename(string const & filename)
| {
| static int counter;
| return convert(counter++) + mangled(filename);
| }
I dont' tlike that temp files are made anonymous like this.
--
Lgb
Re: generated filenames too long
Andre Poenitz wrote:
> On Wed, Jun 15, 2005 at 09:10:48AM +0200, Stefan Kostner wrote:
>> That's a good point, but still I think that skipping the full path and
>> keeping the filename only would be a good option.
>
> This is not sufficient if you have files of the same name in different
> directories...
Well actually it is, because the code is something like:
string const make_tempfilename(string const & filename)
{
static int counter;
return convert(counter++) + mangled(filename);
}
--
Angus
Re: generated filenames too long
On Wed, Jun 15, 2005 at 09:10:48AM +0200, Stefan Kostner wrote: > That's a good point, but still I think that skipping the full path and > keeping the filename only would be a good option. This is not sufficient if you have files of the same name in different directories... Andre'
Re: generated filenames too long
Hi Andre, On Jun 13, 2005, at 9:27 PM, Andre Poenitz wrote: On Mon, Jun 13, 2005 at 07:42:15PM +0200, Stefan Kostner wrote: Stefan Kostner wrote: This means that the filenames of the eps files can be extremely long causing tools like dvips to crash with either segfault or for instance "dvips: ! out of string space". Looks like a fundamental limitation. We don't add characters to the path, just replace them. If your path has more than PATH_MAX characters, you've lucked out. So, why not using other filenames. Since those files are only of temporary nature they could just be numberd, or a combination of numbers and the real filename (without the full path), or only a relative paths...? The idea was to leave the user with some information were things came from in case anything went wrong. Just having an error message 'lyxtmp133241.pdf corrupt' is not very helpful. That's a good point, but still I think that skipping the full path and keeping the filename only would be a good option. In this case the information about the files being processed is still there but the filenames are shorter. It would also help to use the relative path between document and images instead of the full path. Then there is also no way to mix up same filenames included from different directories while keeping the full information. regards, stefan
Re: generated filenames too long
On Mon, Jun 13, 2005 at 07:42:15PM +0200, Stefan Kostner wrote: > >Stefan Kostner wrote: > >>This means that the filenames of the eps files can be extremely long > >>causing tools like dvips to crash with either segfault or > >>for instance "dvips: ! out of string space". > > > >Looks like a fundamental limitation. We don't add characters to the > >path, > >just replace them. If your path has more than PATH_MAX characters, > >you've > >lucked out. > > So, why not using other filenames. Since those files are only of > temporary nature they could just be numberd, or a combination of > numbers and the real filename (without the full path), or only a > relative paths...? The idea was to leave the user with some information were things came from in case anything went wrong. Just having an error message 'lyxtmp133241.pdf corrupt' is not very helpful. Andre'
Re: generated filenames too long
> "Stefan" == Stefan Kostner <[EMAIL PROTECTED]> writes: >> Stefan Kostner wrote: >>> This means that the filenames of the eps files can be extremely >>> long causing tools like dvips to crash with either segfault or for >>> instance "dvips: ! out of string space". >> Looks like a fundamental limitation. We don't add characters to >> the path, just replace them. If your path has more than PATH_MAX >> characters, you've lucked out. Stefan> So, why not using other filenames. Since those files are only Stefan> of temporary nature they could just be numberd, or a Stefan> combination of numbers and the real filename (without the full Stefan> path), or only a relative paths...? Yes, this is probably what we should do, but I do not know what amount of change this would require. JMarc
Re: generated filenames too long
Stefan Kostner wrote: This means that the filenames of the eps files can be extremely long causing tools like dvips to crash with either segfault or for instance "dvips: ! out of string space". Looks like a fundamental limitation. We don't add characters to the path, just replace them. If your path has more than PATH_MAX characters, you've lucked out. So, why not using other filenames. Since those files are only of temporary nature they could just be numberd, or a combination of numbers and the real filename (without the full path), or only a relative paths...? My (not very convenient) workaround at the moment is to copy the directory containing the project to the root of the filesystem for conversion. I am using lyx 1.3.5 on MacOSX and the fink tetex installation. Then you are in luck, I think. Isn't MacOSX a unix OS? That means it supports symbolic links So from your document directory: $ ln -s /long/and/complex/path/to/image/directory images Unfortunately this does not help. Even if we use a symbolic link, the filename of the eps file that is being generated for the latex run contains all characters of the full absolute path. Any symbolic link is resolved for that operation. So, the actual limitation is that all the images used in a lyx project are not allowed to have a long pathname. regards, Stefan
Re: generated filenames too long
Stefan Kostner wrote: > This means that the filenames of the eps files can be extremely long > causing tools like dvips to crash with either segfault or > for instance "dvips: ! out of string space". Looks like a fundamental limitation. We don't add characters to the path, just replace them. If your path has more than PATH_MAX characters, you've lucked out. > My (not very convenient) workaround at the moment is to copy the > directory containing the project to the root of the filesystem for > conversion. > > I am using lyx 1.3.5 on MacOSX and the fink tetex installation. Then you are in luck, I think. Isn't MacOSX a unix OS? That means it supports symbolic links So from your document directory: $ ln -s /long/and/complex/path/to/image/directory images google on "symbolic links" MacOSX if you want a graphical tool to help you create these. -- Angus
