Searched refs:ExtendFileC (Results 1 - 5 of 5) sorted by relevance
| /macosx-10.5.8/xnu-1228.15.4/bsd/hfs/hfscommon/headers/ |
| H A D | FileMgrInternal.h | 276 ExtendFileC (ExtendedVCB * vcb,
|
| /macosx-10.5.8/xnu-1228.15.4/bsd/hfs/ |
| H A D | hfs_readwrite.c | 324 retval = MacToVFSError(ExtendFileC (hfsmp, (FCB*)fp, bytesToAdd,
2026 * are allocated by calling ExtendFileC().
2126 * Note: ExtendFileC will Release any blocks on loan and
2128 * since ExtendFileC will account for the virtual blocks.
2132 retval = ExtendFileC(hfsmp, (FCB*)fp, 0, 0,
2172 * should have been allocated in ExtendFileC(). We do not
2402 retval = MacToVFSError(ExtendFileC(VTOVCB(vp),
2695 u_int32_t extendFlags; /* For call to ExtendFileC */
2808 retval = MacToVFSError(ExtendFileC(vcb,
3224 * during MapFileBlockC and ExtendFileC operation
[all...] |
| H A D | hfs_btreeio.c | 353 * The Extents B-tree can't have overflow extents. ExtendFileC will
390 retval = ExtendFileC(vcb, filePtr, bytesToAdd, 0,
426 // XXXdbg ExtendFileC() could have returned an error even though
|
| H A D | hfs_vfsops.c | 3409 error = ExtendFileC(vcb, fp, bitmapblks * vcb->blockSize, 0,
3435 * blocks. Note that ExtendFileC doesn't do this, which is why this
3471 * Note that ExtendFileC will have marked any blocks it allocated, so
|
| /macosx-10.5.8/xnu-1228.15.4/bsd/hfs/hfscommon/Misc/ |
| H A D | FileExtentMapping.c | 44 ExtendFileC Allocate more space to a given file.
365 * The lock taken by callers of ExtendFileC is speculative and
922 OSErr ExtendFileC ( function
1852 * The lock taken by callers of ExtendFileC/TruncateFileC is
|
Completed in 54 milliseconds