#116 relative paths storage

[Frank]

I know there is the relative path option. But this has some shortcomings: you need separate instances for this portable docfetcher installations. And if you want it on NTFS-drives from Linux, it's not possible because you can't change the executable NTFS permission from Linux.

For the absolute paths:
Every file is stored with full path name in the .fdt index file. Isn't this a waste of storage? Why not defining a base path where you begin indexing, and then take all paths relative to this base path.

The advantage (besides of the saved storage): you can modify the base path later, using it as relative path, or changing the base path if you move the content folder or changing the computer.

So my proposal: split absolute paths in a "base path string", stored only once in the index, and using relative paths to this in the index files. The "base path string" could be configurable, when moving the content folder, or just omitting it when using relative path names.

[Nam-Quang Tran]

Hi,

while more configurability is always desirable, it is not clear to me just how many users would actually need this much configurability. In any case, this change would require a massive overhaul of some core functionality of DocFetcher, which is not going to happen anytime soon.

Best regards
q:-) <= Quang

[Frank]

It would be easier to handle if you move directories, or even for the existent relative path option. I have huge PDF collections, it takes several days to index. When I move these to another folder, re-indexing takes long time again. Also it's more elegant if you split the binary programs and the document location for mobile indices.

Is it really so difficult? It would be just one configuration string for the path prefix in the index data, and for creating a filename, just add the prefix string. Besides, it will save a lot of space in the index file. It's just a feature request, keep in mind for future works on the file name handling. Other issues may be more urgent than this one.

[Nam-Quang Tran]

As to why it's difficult to change: The current implementation grew out of many small incremental changes (aka "historical reasons"), which is why the path handling is now quite convoluted and spread over many components. If all this were to be rewritten from scratch, it would of course end up being much simpler. Unfortunately, that's not how it is, so we're going to have to live with the current mess for quite a while.

[Frank]

Ok, let's keep it in mind for future development. In the end I think it will be even simpler with the path prefix, both for portable and fixed installations.