"Bo Peng" <[EMAIL PROTECTED]> writes: >> OK then. To be frank, I did not manage to read all the threads as >> carefully as may be necessary. > > Now, at least we are talking about the same problem, but just to > clarify, do you also care about information leak from relative paths > ../../girlfriends/sally/image.png, or even in tree files such as > girlfriends/sally/image.png?
I do not think that anybody ever mentioned this problem besides you. I do not care personally. > 1. Exactly what is the problem of remembering the source of a bundled > file? If a user uses it, it is his choice. What I mean is that, seeing the explanations you gave yourself about why this feature (bundle a file but remember where it came from) is useful, keeping the information about the file local to the machine where the original file was is _more_ powerful, since each user can have its own copy of this (now mythical) file and decide how to update it. This looks like better than to say "on Bo's computer this file was at /home/bo/myfiles/file.dat". > 2. If you simply can not accept such a filename in .lyx file, you > should disable it for all insets. Care to explain the difference between "in .lyx file" and "for all insets"? And, no, I do not care about file names in insets. > 3. The filename is functional in my proposal. It is useful information > that would assist unbundling on local or another machine. You mean unbundle as AbsDir/home/bo/myfiles/file.dat on _my_ machine? Why would I want _that_? > 4. Using this filename information to code inzipName is the easiest > solution to avoid file conflict so the information will be there > anyway. For example, if I insert /var1/file and /var2/file, I would > code them as LyX.Embed.Abs/var1/file and LyX.Embed.Abs/var2/file. The > importance of using a unique (but OS dependent) inzipName coding > scheme is that when the same file is inserted, I know it is embedded > so I will not embed the same file twice. I have no opinion on these technical matters... JMarc
