On 15 May 08, at 09:42, Dennis Munsie wrote:
It doesn't move the file -- it removes the entry for it in the
directory. Once the reference count for it go to 0, then it gets
"removed" from the filesystem -- i.e, it's space on the filesystem
gets marked as being available.
On a standard UNIX fil
It doesn't move the file -- it removes the entry for it in the
directory. Once the reference count for it go to 0, then it gets
"removed" from the filesystem -- i.e, it's space on the filesystem
gets marked as being available.
dennis
On Wed, May 14, 2008 at 11:05 AM, Jean-Daniel Dupas
<[EMAIL PR
Le 14 mai 08 à 16:32, Mike Fischer a écrit :
Am 14.05.2008 um 15:32 schrieb Michael Vannorsdel
<[EMAIL PROTECTED]>:
I was going to with sample code to show it, but I didn't see any
documentation that said file locks and link counts were guaranteed.
See man unlink:
"[...] If that decrement
Am 14.05.2008 um 15:32 schrieb Michael Vannorsdel <[EMAIL PROTECTED]>:
I was going to with sample code to show it, but I didn't see any
documentation that said file locks and link counts were guaranteed.
See man unlink:
"[...] If that decrement reduces the link count of the file to zero,
and
I was going to with sample code to show it, but I didn't see any
documentation that said file locks and link counts were guaranteed.
The Finder (or its underlying API) was smart enough to check link
counts and gave notice the file was inuse. But rm just wiped it off
the FS and left nothing
Obviously this is less efficient than mapping which is why mapping is
still around. But it's kinda the only other option when mapping and
FS operations won't protect your mapped file. My point was that the
program and system will still run under heavy memory consumption,
albeit slowly. J
On 13 May '08, at 8:57 PM, Michael Vannorsdel wrote:
I actually tested this a month back and not all operations/programs
respect link counts nor does the system appear to enforce them. For
instance an rm -f will destroy the file regardless of link count, as
well as some obscure APIs. Aft
On 13 May '08, at 9:39 PM, Michael Vannorsdel wrote:
If there's some pages of your data you haven't touched in a while
the system will swap those out and use the physical pages for
something that needs them.
Yes, but it's less efficient than a mapped file, which doesn't have to
be swappe
I suggest reading in the entire file into your NSData with
initWithContentsOfFile: if there's a significant chance of file
modification. I know this sounds like a huge memory usage but this
way you can know your data is static and the system is designed to
handle high memory usage programs
Also I should add, I've yet to find a way to protect a file from
editing or deletion on OS X that can't just be ignored by something
else. Things like flock appear to be optionally supported and not
globally enforced. As long as a way exists to get around any kind of
file lock there's no
I actually tested this a month back and not all operations/programs
respect link counts nor does the system appear to enforce them. For
instance an rm -f will destroy the file regardless of link count, as
well as some obscure APIs. After the file was removed the mapping
program crashed wh
On 13 May '08, at 12:55 PM, Daniel Vollmer wrote:
It sounds like you're creating a single NSString containing the
entire contents of the file, then?
Yes. Is that something I shouldn't do? I mean, I feel a tiny bit
silly creating such huge strings but I didn't find a nice
alternative (e.g
On May 13, 2008, at 17:00, Jens Alfke wrote:
On 12 May '08, at 11:38 PM, Daniel Vollmer wrote:
I'm parsing a rather large text-file (usually >20MB) and in doing
so I'm iterating over its lines with [String
getParagraphStart]. I've found a rather noticeable speed-up in
the parsing op
On May 13, 2008, at 8:08 AM, Jens Alfke wrote:
While we're on the topic, it's worth noting that memory-mapping
files on removable or network filesystems can be dangerous. If you
read/write a mapped memory location, and the kernel has to page it
in, but the file's filesystem is no longer ac
On 13 May '08, at 12:15 AM, Michael Vannorsdel wrote:
Basically there's no guarantee you'll get the same data that was in
the file when you first mapped it if something else modifies or
destroys it while it's mapped.
You're correct about modifications, but not about deletions. An open
fi
On 12 May '08, at 11:38 PM, Daniel Vollmer wrote:
I'm parsing a rather large text-file (usually >20MB) and in doing so
I'm iterating over its lines with [String getParagraphStart].
I've found a rather noticeable speed-up in the parsing operation if
I create the string in question from
On May 13, 2008, at 12:38 AM, Daniel Vollmer wrote:
Salutations!
I'm parsing a rather large text-file (usually >20MB) and in doing so
I'm iterating over its lines with [String getParagraphStart].
I've found a rather noticeable speed-up in the parsing operation if
I create the string i
Salutations!
I'm parsing a rather large text-file (usually >20MB) and in doing so
I'm iterating over its lines with [String getParagraphStart]. I've
found a rather noticeable speed-up in the parsing operation if I
create the string in question from an NSData object (created via
initWi
18 matches
Mail list logo
