Archive: Problem with LineFind and attributs


Problem with LineFind and attributs
Hello,

I hope you'll understand my problem with my poor english...

Well, I use ${LineFind} to replace some lines of a file.
All is ok.
But I can't write or even read the file when I'm not on the server where I used my setup.
To use the file, I must go on the server and change the safety (I'm not sure it's the good word in english) of the file (all rights for everybody).

Of course, before use LineFind, I can read the file when I'm not on the server.

I hope my explanations are enough clear.

If you have an idea, thanks for your help.


I don't know why, but it opens the file for writing and writes something to it. It also has code that copies over a file, but I'm not sure the it's the same file. Instructor will know best, he wrote the function.


As I understand you are trying to modify/read the text file that is located on the server? If you have access rights "only read" and use call like:

${LineFind} "\\server\data\a.log" "" "1:-1" "LineFindCallback"
then will be error because function trying to modify "\\server\data\a.log". Just use local disk for the output file (if you have full access :) ).
${LineFind} "\\server\data\a.log" "C:\a.log" "1:-1" "LineFindCallback"
If you want only read LineFind have option "/NUL".

Ok, my english is really poor. :(

I can modify the file with the setup.
When the installation is finished, if I want to read the modified file when I'm not on the server, I can't, attributs of the file are différent before and after the setup.

Before the setup write the file, I have full access to the file, after, I can't read it...


LineFind creates a file with normal attributes in any way. I now trying to find the solution.


If you have access rights "only read" and use call like [the code shown on Instructor's post] then will be error because function trying to modify "\\server\data\a.log".
I think you should use ${LineRead} if you just want to read a line of the file.

My opinion is that a function called "LineFind" should only find if a line exists, and not even read it (there is the "LineRead" function for that), nor to write the line of the selection chosen (maybe a new function for this?). But still, either the function name is wrong or are its features. I would suggest the function name to be "LineSelect" because it is actually selecting which lines should be written to another file.

:) I long time thought about what name give to function and was choosing between several not exhaustive names. I like your variant "LineSelect" unfotunately it doesn't come to me when I thought.


I think you should use ${LineRead} if you just want to read a line of the file.
My mistake. You really wanted to replace lines in the file. Maybe you could use the ${GetFileAttributes} to get the file attributes then set it back again with the SetFileAttributes NSIS instruction. It even outputs the result compatible with the attribute input parameter of the instruction.

Now about making ${LineSelect} to have this functionality as well: I actually think you should either mention to use ${GetFileAttributes} w/ SetFileAttributes to put them inside the function.

Maybe it would be even better to create other types of functions just to, for example, specificly replace a file, then you could make sure of the attributes of the file being replaced and calling this function from other functions and simplifying even more code. A drawback would be including every single function by hand or by creating a header file, and the amount of calls. That's what I simplified on UseFunc, but nobody actually wanted something to be improved on it, so I just about abandoned it (still sometimes working on it). I know my contrib is not the best, but some comment for improvement would suffice.

Maybe you could use the ${GetFileAttributes} to get the file attributes then set it back again with the SetFileAttributes NSIS instruction.
attribute1|attribute2|... of SetFileAttributes sets on compile-time.
Maybe it would be even better to create other types of functions just to, for example, specificly replace a file, then you could make sure of the attributes of the file being replaced and calling this function from other functions and simplifying even more code.
I think it is better to write an example for user how to do some concrete things using basic functions rather than increase size of the installer by calling another function internally.
.. but some comment for improvement would suffice.
Why in usefunc.zip so many empty directories? :)

I don't think it's the best way, but this is my solution.
I use CopyFiles, in fact, I edit a temporary file and copy it with the good name.
I can't read the temporary file but I can do it with the copy...

Don't know why:weird:

Thanks for your helps


attribute1|attribute2|... of SetFileAttributes sets on compile-time.
^^ Idea for run-time function right there.

Why in usefunc.zip so many empty directories?
The zip file is designed to be extracted to NSIS dir.... Greaaat comment, thx ;).

EDIT:
I think it is better to write an example for user how to do some concrete things using basic functions rather than increase size of the installer by calling another function internally.
Not always. Macro is still better than giving examples because they do not add anything than just putting code right on except by compilation time. I would still recommend both the automatic method (function macro w/ calls done to other functions) and the manual method (function macro w/ all the code optimized).

I will experiment with the attributes and LineFind, and you can try this:
http://forums.winamp.com/showthread....hreadid=234814