Unable to import old libraries due to lack of 'filename' field in version 1.2.1

Bug #1228467 reported by m4cph1sto
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Referencer
Confirmed
Medium
Unassigned

Bug Description

I am upgrading from Referencer 1.1.6 to version 1.2.1. My old libraries from 1.1.6 have two fields for the local document location: "filename" and "relative_filename". In all my old libraries (going back to 2009), the "relative_filename" field only contains the file name, no path information. The "filename" field contains the full path to the document (e.g. file:///home/user/and-so-on/file.pdf). It appears that Referencer 1.2.1 no longer uses the complete "filename" field, and is only looking for the "relative_filename" field when I open my old libraries. When I create a new library in 1.2.1, only the "relative_filename" field is written to the library; the "filename" field containing the complete path is missing. Since no path info is contained in the "relative_filename" field in the libraries generated by the older versions of referencer (I don't know why, maybe an old bug?), the file locations are all lost when the library is opened in Referencer 1.2.1. For this reason I cannot use the latest version of Referencer.

I suppose this could be fixed by re-introducing the "filename" field with the full path to the documents. Another fix would be to write a script to copy the correct relative path info to the "relative_filename" field in the libraries generated by previous versions of Referencer, so that they can be successfully opened in Referencer 1.2.1.

Revision history for this message
m4cph1sto (dlreid) wrote :

Ok I found the source of the problem, and I don't think a patch is strictly needed. In version 1.2.1 I see in Document.C (line 464) that Referencer now prefers to use only relative filenames in the library XML file, and only reads for a full filename if no relative filename is found. This seems like good practice in general. My problem arose because of what I assume was a bug in version 1.1.6 that stripped the path locations out of the relative_filename fields, so it only contained the name of the file. If the relative_filename field were just empty, Referencer 1.2.1 would look for the full filename and would still find the document. But since relative_filename contained just the name of the file, Referencer doesn't find the document and gives an error.

I solved my problem simply enough: deleted all the <relative_filename> lines from my old library file, opened it in Referencer 1.2.1, then re-saved it, which re-populated the relative_filename fields with all the correct file locations.

There probably won't be many users who have this same problem, unless they are also coming from version 1.1.6 with an old library file. But if it's worth the trouble, it might be best to have Referencer still write the full filename info in the library XML file, and read from it not only if relative_filename is missing, but also if it results in a file not found, for us old users.

Revision history for this message
m4cph1sto (dlreid) wrote :

For anyone reading this who has the same problem, just run this command on your old library file, then open the new file in Referencer 1.2.1, verify you have the correct library location under preferences, then save the file:

sed '/<relative_filename>/d' ./old-library.reflib > ./new-library.reflib

Revision history for this message
Mads Chr. Olesen (shiyee) wrote :

The reason we wanted to get rid of the absolute paths were that it made sharing of libraries between different users/machines very difficult. I was unaware of the old bug in 1.1.6 of not writing relative paths.

I think a patch to read the absolute path if the relative path is empty would be acceptable, if someone wants to do it.

Changed in referencer:
status: New → Confirmed
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.