Jabref: Offer truncation of file names during file renaming

Created on 2 Apr 2018  路  18Comments  路  Source: JabRef/jabref

Previously I used \bibtexkey\begin{title} - \format[Replace("(.{90}).*,$1", RemoveBrackets]{\title}\end{title} for renaming pdf files when cleaning. But this does not work currently.
Found this link.
i.e., [bibtexkey] - [title]. But how to truncate the filename up to certain length(number) (say 90 or 100).
Basically, I want to replace the 1st expression to make things work, but not able to do it.

good first issue documentation enhancement

All 18 comments

Hi, the format is now the same as for the bibtex key generator:
http://help.jabref.org/en/BibtexKeyPatterns#special-field-markers

Yes, I want like this: [auth:lower][year][veryshorttitle:lower]:[title]. But, in addition, I want to truncate the filename up to 100 and spacing. E.g.: For the title, _An awesome paper on JabRef_, say bibtexkey is _bibkey_, and want to truncate up to 25. Then the file name I want is: bibkey - An awesome paper.pdf

Note that it currently seems to be impossible to truncate the result. If that is the only additional requirement to our formerly known "label patterns" (now "Bibtex Key Patterns"), we maybe should offer a configuration option for that.

Is this included in version 5.x?

It doesn't seem like that. You're welcome to submit a pull request 馃槆

I can take a look at this issue.

Would these steps make sense as a solution?

  1. Add a field for replacing the filename with regex in Options -> Preferences -> Import, which would make similar to the BibTeX key generator. A pattern along the line of (?<=\A.{0,90}+).* should solve @pramitbiswas's issue in that case? (the pattern hopefully matches everything except the first 90 characters)
  2. In the "Cleanup entries", update to show the regex along with the current pattern.

@k3KAW8Pnf7mkmdSMPHz27 The cleanup rename/moving takes two pattern, the fileDirPattern for naming the (sub)directory and the filenamePattern. Both use the same syntax as the ones for the bibtexkeypattern.

I think I would decouple the cases here.

  1. Generate the bibtex key using the defined pattern (independent of the cleanup, a user can already auto generate keys)
  2. Create a filename pattern based on bibtexkey

What's now missing is a TruncateModifier, which acts like the modifiers here:
https://docs.jabref.org/setup/bibtexkeypatterns#modifiers

In the end the filenamepattern could look like this:
[bibtexkey:truncate(40)]

@Siedlerchr, I'll get started on truncate, but I am not sure I understand what the use case is. I thought, perhaps erroneously, that pramitbiswas wanted to truncate the full filename (excluding the extension).
If this is not the use case, feel free to ignore everything below this line ^^

Everything from here on is under the assumption that the use case is to truncate the full filename. I can think of three approaches,

  1. Just implementing :truncate(). However, I can't get "stacked patterns" to work, e.g., [[year][auth]:lower] does not produce the result that I expect. I am not a JabRef power user so perhaps there is an error with the human :P
    If "stacked patterns" are not supposed to work, should I attempt to add that feature?

  2. Add the same replace with regex option that currently exists for BibTex key generation. But perhaps this is inconvenient to use.

  3. As it currently is, only using the [bibtexkey] as a filepattern and "pre-truncating" it with regex in the BibTex key generation should work but it inconvenient and most definitively does not decouple the cases.

I would also go with the truncate modifier as @Siedlerchr suggests. Seems to be the most flexible solution from which also other users profit (although it might not be exactly what @pramitbiswas was suggesting).

The stacked pattern is a nice idea. I may warn you, however, that the code surrounding the pattern parser is really ugly / inflexible. So this might be hard to implement.

@tobiasdiez, I'd guess the consensus is that :truncate would "solve" this issue then?

I can have a look at the pattern parser while I am at it and see if I would enjoy/be able to change it. If that is the case, should I add a feature request and suggest myself to solve it later?

Meanwhile, perhaps using the regex and only [bibtexkey] as a filepattern works as a temporary "fix" for @pramitbiswas.

Good! There is no need to open a feature request. If you fell like implementing it, please go ahead and open a PR!

First of all, thank you very much for taking the issue forward.

Suppose for this bib entry

  • I rename the file name as: davcev2018iot - IoT agriculture system based on LoRaWAN. The first part is davcev2018iot is the bibtexkey. I have absolutely no issue with it. As described here, my problem is with final file name length (excluding extension, of course).

  • Sometimes what happens was, due to either big title of the paper or very deep nested directory or both, I can not copy/move the file elsewhere due to path length (probably max is 255), this is the actual reason for truncating the file name to a low length.

I saw the description in PR, I think it will solve the issue for me. The solution to the mentioned problem is [bibtexkey] - [title:truncateN]

@pramitbiswas you get a "java.nio.file.FileSystemException: " ... "File name too long" error message from JabRef when the problem occurs? (That is what happens when I am trying to recreate the error on a FAT drive which is quite limited in path length)

Normally jabref auto truncates long file names. There is at least a method in FileUtil class

I can't reproduce the error on what my system calls DOS_FAT_32 after applying the auto truncate to directory names (limiting them to a length of 255).

For reference: The PR where the system was changed is https://github.com/JabRef/jabref/pull/3238.

Thanks to @k3KAW8Pnf7mkmdSMPHz27 this is now implemented in the latest development version. Could you please check the build from http://builds.jabref.org/master/. Thanks! Please remember to make a backup of your library before trying-out this version.

Was this page helpful?
0 / 5 - 0 ratings