prepend to file

[amslo...@gmail.com]

Hi - 

How can I prepend to a file? Similar to a stack.

For example -> if you usually write to a file, the output would look like the below -

output

output|append

output|append|append

but in my case I want it look like this - 

output|append|append

output|append

output

[Scott Lawrence]

You can't. It's not a limitation of go - it's a limitation of files. You would
have to re-write the entire file, by reading it in, then truncating, then
writing what you wish to prepend, then writing the buffer you read in.

>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--
Scott Lawrence

go version go1.0.3
Linux baidar 3.8.3-2-ARCH #1 SMP PREEMPT Sun Mar 17 13:04:22 CET 2013 x86_64 GNU/Linux

[Michael Jones]

do you mean this?

original

A|original

B|A|original

C|B|A|original

:

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[amslo...@gmail.com]

Michael - Yes, you are correct. 

[Michael Jones]

On Thu, Mar 28, 2013 at 1:12 PM, <amslo...@gmail.com> wrote:

Michael - Yes, you are correct. 

On Thursday, March 28, 2013 3:53:17 PM UTC-4, Michael Jones wrote:

do you mean this?

original

A|original

B|A|original

C|B|A|original

:

Ok, then as Scott said shared, this is not how files in file systems work. (They could work this way, but they don't. The conceptual model that is implemented is to start with zero bytes in a file ("an empty file") and to add bytes to the end. Think of an infinite scroll where you start writing at the top of the scroll and keep writing on an ever extending length of paper...

...now it need not be that way, the file mechanism actually is not implemented this way. In reality small chunks are added as the file gets longer and longer and these chunks are linked together by metadata in the file system to make it seem that it works this way. It could be done differently so that the chunks could be linked from either end of the file, which would (conceptually) have you writing on a "double ended scroll" that could get longer in either direction.

You can implement this pretense with two files, one that represents bytes 0..infinity in the normal sense, and another that represents (so to speak) bytes -1, -2, -3 and so on going backward either byte at a time or line at a time. In this scheme you can append to either end, seek and read, and everything else that normal files do, but with the magic bidirectionality of your "double-scroll" file system.

;-)

[John Nagle]

On 3/28/2013 12:45 PM,

More clarity is required. Do you need a really big stack?
An output file in reverse order? Are the items of variable or
fixed length? Generally, you'll have to write forwards once,
then read backwards while writing a second file to reverse.

A key component needed is the ability to read a file in
reverse. This is quite possible, although not a standard
feature of Go.

What are you trying to do? And on how much data?

John Nagle

[Ian Lance Taylor]

On Thu, Mar 28, 2013 at 1:41 PM, Michael Jones <m...@google.com> wrote:

Ok, then as Scott said shared, this is not how files in file systems work. (They could work this way, but they don't. The conceptual model that is implemented is to start with zero bytes in a file ("an empty file") and to add bytes to the end. Think of an infinite scroll where you start writing at the top of the scroll and keep writing on an ever extending length of paper...

I see that Michael uses the well-known medieval scroll file system (MSFS) on his computer.  Or perhaps it's the renaissance scroll file system (RSFS); I always get those confused.

Ian

[Rob Pike]

No one has mentioned the Unicode bidi algorithm in this thread.

-rob

[Michael Jones]

Or troff's boustrophedon flag...

On Thu, Mar 28, 2013 at 2:13 PM, Rob Pike <r...@golang.org> wrote:

No one has mentioned the Unicode bidi algorithm in this thread.

-rob

[Caleb Doxsey]

I'd store it in reverse order. Like normally if you had:

[a, b]

You'd store

length of a, a's bytes, length of b, b's bytes

Instead I'd store:

b's bytes, length of b, a's bytes, length of a

In binary:

61 0000 0000 0000 0001 62 0000 0000 0000 0001

Writing is then straightforward, and reading involves seeking to the end of the file, reading the length, and then reading the value. Like this:

http://play.golang.org/p/XKDc9FONZ7

You can use f.Truncate to implement Pop.