On Thursday 03 April 2008 18:05:32 Bo Peng wrote: > I guess your 'external' means 'files with absolute path'. With the new > policy that they should not be extracted outside of the document > directory, these files will always be used so their original path > information may not be important.
OK, we agree here. > However, > > 1. They can be there, maybe in gray color, to tell users where the > files are embedded. To be useful under your conditions this file needs to be changed. You can decide to use another source or during a reorganization its location may change. > 2. During unbundling, the external version will be compared with the > embedded version. If the external version exist, and is identical to > the embedded file, there is no need to unbundle this file to the > document directory. That is to say, you *do not have to* extract these > files to the document directory to successfully unbundle a file. If it was not clear I think that by security considerations we should not extract the files to the current directory but to a new/fresh directory. This means that the files are in a new namespace that will be translated to a new directory. > 3. Not writing outside of document directory does not have to mean I > can not *read* outside of the document directory. Such files can still > be updated from an external file if a user wants to do so. OK. > > > If you are talking about 'update from external file' of an embedded > > > inset, this is done after lyx gets started, and I do not see a reason > > > to call python for this simple task. > > > > You are proposing to add the original external file path in order to > > allow a later update. This information is only useful for the computer > > where the file was created. > > Yes. This is my dirty trick (you will dislike this word) to keep my > out of tree files. Because these files are rarely modified, I expect > to unbundle my .lyx files successfully under my computer(s) without > having to copy them to my document directory. On other systems, the > 'update from external file' menu item will be disable if a matching > file is not found. At this level I dislike dirty tricks. We have been considering for years the expansion of the external insets and we have never done precisely because of these kinds of problems. Security is an important issue. The original file path of embedded files should not be saved in the lyx file. If you, a power user, want to keep an accounting of the embedded files and its original source that is acceptable but this feature should not be in standard lyx even if optional. As I said it is easy to do this in python (or any other scripting language fwiw). > > You are proposing to put this information in the lyx file and as I said > > before we could put this information at the same level as the session > > stuff because as the session stuff it only makes sense in the original > > computer. > > But of course another computer 'can' have these files. In my case, I > have my complete svn tree on a few different machines. linux or > windows. > > > If we put the original file in the lyx file we are leaking information > > that we should not, none should care about the original file location > > other than the author. > > If you mean the file content, it is not leaking because they are used > in the document. No I mean the file path. > If you are talking about file path, this is what we > have been doing for ages. The file path will be there if such a file > is used. The new approach can help a little bit by hiding the path > because it is no longer needed by the user (and rarely needed by lyx > itself). If the file path is not necessary it should not be there. Less is more. Again this information is only relevant in one machine just like the cursor position. For me they are the same type of information, where as been your last cursor position in a file and what was your original file path, even if that path is relative. They should not be leaked if a file is transferred. > Bo -- José Abílio
