time is running
[257 byte] By [alcatraz123a] at [2007-11-27 9:10:10] 
hi, i've got few files with 13,000 lines each one. i want to write to each file one line in the beginning. and i want to do this very fast without reading each line. is there any method to write in the beginning? thanks for any advice. best regardfs
No.
If you're going to write something at the front of a file, you'll have to write that out to a temp file, then read the rest of the original file and append it to that temp file, then delete the original and rename the temp file to the original. There's no way to just insert in the front of an existing file.
jverda at 2007-7-12 21:51:11 >
No way.You can append in the end.But not in beginning of the file.
pbulgarellia at 2007-7-12 21:51:11 >
i'm asking why, it is so hard to write in the beginningstrange?
alcatraz123a at 2007-7-12 21:51:11 >
Think about it. To get something in at the beginning of a file, you would have to shift everything else along a bit.
DavidKNa at 2007-7-12 21:51:11 >
> i'm asking why, it is so hard to write in the> beginningstrange?It's the way filesystems are designed.
hunter9000a at 2007-7-12 21:51:11 >
> It's the way filesystems are designed.
Hmmm, I don't see any fundamental reason why a filesystem couldn't write a new fragment, and just "slip it in" by allocating it as the first fragment of the file.
One suspects that it's possible in assembler, but it was omitted the 3GL API's because it wasn't consider bang for your buck in terms of complexity vs utility.
or am I missing something fundamental (again)?
Keith.
Message was edited by: corlettk
corlettka at 2007-7-12 21:51:11 >
> hi, i've got few files with 13,000 lines each one. i
> want to write to each file one line in the beginning.
> and i want to do this very fast without reading each
> line. is there any method to write in the beginning?
> thanks for any advice. best regardfs
As already pointed out, you'll have to write the first line then copy the rest over it; but the good news is that you wouldn't necessarily have to read the old file line-by-line (i.e., you wouldn't need to parse the file looking for line endings). This might speed things up a little bit.
paulcwa at 2007-7-12 21:51:11 >
> > It's the way filesystems are designed.
>
> Hmmm, I don't see any fundamental reason why a
> filesystem couldn't write a new fragment, and just
> "slip it in" by allocating it as the first fragment
> of the file.
>
> One suspects that it's possible in assembler, but it
> was omitted the 3GL API's because it wasn't consider
> bang for your buck in terms of complexity vs
> utility.
I suppose you could fiddle with the file system structures to do something like that...but I've never heard of a system library providing such functionality.
Though that proves nothing, of course.
paulcwa at 2007-7-12 21:51:11 >
I don't know twaddle about file systems, so this is just off the top of my head...
Basically a file is a list of blocks, right? It would not be hard to allow a block to be inserted at an arbitrary position in the list.
However, at the byte level, a file is more like an array--sequential physical locations. If you want to insert a byte in an arbitrary spot, you have to copy every following byte to the next later spot. OR there would have to be some indexing scheme in place.
I suppose if you want to insert one or several bytes an an arbitrary spot, you could insert a block, have some record keeping that says that the previous block ends at index whatever, and the inserted one ends at index whatever, but that would get messy fast. You'd either end up wasting lots of bytes for inserted blocks that have just a few bytes, or you'd have to to a lot of extra work to consolidate blocks when possible and not too intrusive.
jverda at 2007-7-12 21:51:11 >
Well, yeah. As I recall from OS class years ago, typically a file system is a linked list of blocks. Each block can hold up to its limit of data.
Theoretically, you could munge the linked list, adding a new block in an arbitrary location. But as you identify, this could lead to poor block usage. One could, I suppose, de-fragment their disk a lot more to compensate. Also the API could hopefully be smart enough to reduce the trouble as it happens (e.g., check to see if there's enough spare room in an existing block for the new content, before adding a new block).
And in practice, modifying a file seems to fall into two main cases:
1) appending at the end of the file (e.g. for log files)
2) doing major modifications, far more complicated that just inserting new bytes at arbitrary locations.
As such, APIs tend to deal with those two cases with the familiar append and overwrite modes, and anything that doesn't fall into cases 1 and 2 above is handled with overwrite mode.
paulcwa at 2007-7-12 21:51:11 >
Java Essentials New Topic
Java Essentials Hot Topic
Java Essentials
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding