ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I'm trying to write a CGI scrip to upadte a file with comments, however I want the newest to appear first in the file, which is included into a html dock with php include.
However How can I append the below to the beginning of the comment file? (I'm hoping not to have to make a new file with the new comment, append the old file to the end, delete the old file and rename the new.)
no shortcut for this as far as I can tell. Open the file to read, read the file into memory, close the file. Reopen the file for writing. Write the new first record, write the remainder of the file from memory.
1. Create temp file
2. Write header to temp file
3. Open old file
4. For each line in old file
Read line from old
Write line to temp
5. Close both files
6. Rename temp file to old filename
Thanks for the responce,I've spent pretty much a day looking on the net for a solution, and haven't yet. I refuse to beleive that its not possible! I've come across this
int fseek(FILE *stream, long offset, int relative_to);
I've been trying to use it after: out = fopen(COMMENT_FILE, "a+"); to put the file pointer to 0, bt although it compiles with no errors or warnings, it does nothing. I'm not sure if I'm using right, or if I've missed ther point of the perpose of this.
I don't know of any current filesystem design that allows this. However, the design of many *nix filesystems are almost ripe for such an idea. The basic part of the FS is the inode, and the part we might be concerned is the list of data blocks that are contained in the inode. I can imagine a design that allows a special call that replaces the first pointer to a data block with the new one, and the remaining pointers shuffled down. The problems that arise are that the data might need to be padded with some representation of do-nothing-with-this-kind-of-character data, and, once you get to the indirect blocks, you really need to do some dancing.
So, in practice, writing a new file is the easiest.
However, one could also write a file that is indexed (i.e. a random file), and then you don't care where the data blocks are physically, you just update the index. So this would be like playing with the inode, but you get to do it in your space. Reading it back in requires the program to read the index and pick the data blocks in index order, but if the application is important enough, and particularly if the data collection is large enough, it's worth some extra effort.
Makyo, Thanks for the responce, but a little bit over my head. I think I'm going to play around with reading the origanl file into memory, and then re-write the lot. If I do come across a solution, I'll post it here. Thanks for the help guys!
The problems that arise are that the data might need to be padded with some representation of do-nothing-with-this-kind-of-character data
And that could lead to quite a lot of disk that cannot be accessed. If an inode reserves 4Kb of disk space and you are appending a single log line (let's go for 100 bytes of data) Then you have a lot of waste, a 1Mb log file would take 40Mb of disk space.
Such an implementation would require a feature to compress the file (and free up inodes). So I would suggest that it would be easier to read the whole file in, modify it in memory and then write the modified (in this case appended) file back out.
No argument there. However, if we were adding 100 MB chunks, it would look much better. Not to mention -- when was the last time anyone worried a lot about disk space? Still, your point is well-taken.
Blue-skying is useful to consider what could be done. I certainly don't have the expertise to perform even the design of that change. I had wanted to do that same user task for a long time, and, for my purposes, I wrote a prepend script to accomplish that task -- it did just as everyone agreed, but if something in *nix changes, I'll be ready to slide that new method in.
In some applications, it is useful to trade space for time -- particularly in a close-to-real-time situation so that we can provide good response at the expense of wasted space.
I have not looked deeply at current system implementations, but in the past one large system on which I did application programming expanded the size of the inodes, and placed small data files directly in the inode -- very, very clever, I thought.
I hadn't really thought about compression, but that's one of the chores that the system could do in wee small hours of the morning when the users are sleeping and the elves are working.
For the current situation, I agree, do the simple, practical thing, and keep thinking and working about could be. We need to say "I want", so that developers and vendors know our desires. Thanks for your comments, best wishes ... cheers, makyo