Re: Is cloning the same as copying in APFS?

[Rick Mann]

Yeah, our data is immutable, so hard Link’s work fine. 

-- 
Rick Mann
rm...@latencyzero.com

> On Jun 28, 2017, at 02:43, Alastair Houghton  
> wrote:
> 
>> On 27 Jun 2017, at 22:45, Rick Mann  wrote:
>> 
>> Agreed. Thanks for the code, and for showing the other techniques. In my 
>> case, I still have to support HFS+, and I want to do that with hard links. I 
>> wish there was an API to clone-or-hardlink, but I can do that.
> 
> Perhaps worth emphasising here, since you mention hard links, that the 
> difference between hard links and clones is that clones are copy-on-write.  
> i.e. if you hard link a file, and then change the data, *all of the linked 
> copies will change too*.
> 
> I’m sure that’s not an issue in your application, but if someone later 
> happens across this thread and thinks “What a great idea!”, mentioning that 
> the two are only equivalent for the read-only case might avoid some pain.
> 
> Kind regards,
> 
> Alastair.
> 
> --
> http://alastairs-place.net
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Alastair Houghton]

On 27 Jun 2017, at 22:45, Rick Mann  wrote:
> 
> Agreed. Thanks for the code, and for showing the other techniques. In my 
> case, I still have to support HFS+, and I want to do that with hard links. I 
> wish there was an API to clone-or-hardlink, but I can do that.

Perhaps worth emphasising here, since you mention hard links, that the 
difference between hard links and clones is that clones are copy-on-write.  
i.e. if you hard link a file, and then change the data, *all of the linked 
copies will change too*.

I’m sure that’s not an issue in your application, but if someone later happens 
across this thread and thinks “What a great idea!”, mentioning that the two are 
only equivalent for the read-only case might avoid some pain.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Rick Mann]

Yes, that seems the right way to do it. Thanks!

-- 
Rick Mann
rm...@latencyzero.com

> On Jun 27, 2017, at 16:07, Charles Srstka  wrote:
> 
>>> On Jun 27, 2017, at 4:45 PM, Rick Mann  wrote:
>>> 
>>> 
 On Jun 27, 2017, at 14:30 , Charles Srstka  
 wrote:
 
 On Jun 27, 2017, at 4:17 PM, Rick Mann  wrote:
 
 Thanks for that, Charles!
 
 I wasn't sure because of the existence of the clonefile() call in 
 , implying that operation was different from copyfile(), 
 but looking more closely at the sample code, I see that you can call 
 copyfile() with COPYFILE_CLONE, which seems like it will clone if possible 
 and copy if not.
 
 But there didn't seem to be equivalent calls in NSFileManager, hence my 
 question.
>>> 
>>> Apple clearly wants the clone feature to get used. :-) The ability to do a 
>>> copy the old way is still there if you drop down to C, but since I can’t 
>>> think of too many reasons to want to do that, it makes sense to leave it 
>>> out of the high-level API.
>> 
>> Agreed. Thanks for the code, and for showing the other techniques. In my 
>> case, I still have to support HFS+, and I want to do that with hard links. I 
>> wish there was an API to clone-or-hardlink, but I can do that.
> 
> That should be easy enough to do. One thing I’d recommend would be checking 
> the volumeSupportsFileCloningKey key on URLResourceValues, rather than 
> checking the file system type itself. That way, if APFS gets supplanted by 
> some even better file system in the future, you’ll already support it.
> 
> Charles
> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Charles Srstka]

> On Jun 27, 2017, at 4:45 PM, Rick Mann  wrote:
> 
>> 
>> On Jun 27, 2017, at 14:30 , Charles Srstka > > wrote:
>> 
>>> On Jun 27, 2017, at 4:17 PM, Rick Mann >> > wrote:
>>> 
>>> Thanks for that, Charles!
>>> 
>>> I wasn't sure because of the existence of the clonefile() call in 
>>> , implying that operation was different from copyfile(), 
>>> but looking more closely at the sample code, I see that you can call 
>>> copyfile() with COPYFILE_CLONE, which seems like it will clone if possible 
>>> and copy if not.
>>> 
>>> But there didn't seem to be equivalent calls in NSFileManager, hence my 
>>> question.
>> 
>> Apple clearly wants the clone feature to get used. :-) The ability to do a 
>> copy the old way is still there if you drop down to C, but since I can’t 
>> think of too many reasons to want to do that, it makes sense to leave it out 
>> of the high-level API.
> 
> Agreed. Thanks for the code, and for showing the other techniques. In my 
> case, I still have to support HFS+, and I want to do that with hard links. I 
> wish there was an API to clone-or-hardlink, but I can do that.

That should be easy enough to do. One thing I’d recommend would be checking the 
volumeSupportsFileCloningKey key on URLResourceValues, rather than checking the 
file system type itself. That way, if APFS gets supplanted by some even better 
file system in the future, you’ll already support it.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Rick Mann]

> On Jun 27, 2017, at 14:30 , Charles Srstka  wrote:
> 
>> On Jun 27, 2017, at 4:17 PM, Rick Mann  wrote:
>> 
>> Thanks for that, Charles!
>> 
>> I wasn't sure because of the existence of the clonefile() call in 
>> , implying that operation was different from copyfile(), 
>> but looking more closely at the sample code, I see that you can call 
>> copyfile() with COPYFILE_CLONE, which seems like it will clone if possible 
>> and copy if not.
>> 
>> But there didn't seem to be equivalent calls in NSFileManager, hence my 
>> question.
> 
> Apple clearly wants the clone feature to get used. :-) The ability to do a 
> copy the old way is still there if you drop down to C, but since I can’t 
> think of too many reasons to want to do that, it makes sense to leave it out 
> of the high-level API.

Agreed. Thanks for the code, and for showing the other techniques. In my case, 
I still have to support HFS+, and I want to do that with hard links. I wish 
there was an API to clone-or-hardlink, but I can do that.

> 
> Charles
> 


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Charles Srstka]

> On Jun 27, 2017, at 4:17 PM, Rick Mann  wrote:
> 
> Thanks for that, Charles!
> 
> I wasn't sure because of the existence of the clonefile() call in 
> , implying that operation was different from copyfile(), but 
> looking more closely at the sample code, I see that you can call copyfile() 
> with COPYFILE_CLONE, which seems like it will clone if possible and copy if 
> not.
> 
> But there didn't seem to be equivalent calls in NSFileManager, hence my 
> question.

Apple clearly wants the clone feature to get used. :-) The ability to do a copy 
the old way is still there if you drop down to C, but since I can’t think of 
too many reasons to want to do that, it makes sense to leave it out of the 
high-level API.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Rick Mann]

Thanks for that, Charles!

I wasn't sure because of the existence of the clonefile() call in 
, implying that operation was different from copyfile(), but 
looking more closely at the sample code, I see that you can call copyfile() 
with COPYFILE_CLONE, which seems like it will clone if possible and copy if not.

But there didn't seem to be equivalent calls in NSFileManager, hence my 
question.

> On Jun 27, 2017, at 13:55 , Charles Srstka  wrote:
> 
>> On Jun 27, 2017, at 12:28 AM, Jens Alfke  wrote:
>> 
>>> On Jun 26, 2017, at 7:38 PM, Rick Mann  wrote:
>>> 
>>> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
>>> different from a clone.
>> 
>> The low level file copying API that I’m aware of is , which is 
>> Apple specific. It has options for doing copy-on-write.
>> I don’t know if NSFileManager’s copy method clones files. I would assume 
>> that it does, on APFS.
> 
> Well, I mean, you could always *try* it ;-)
> 
> import Foundation
> 
> func unclonedSize(of url: URL) throws -> off_t {
>   var list = attrlist(bitmapcount: UInt16(ATTR_BIT_MAP_COUNT),
>   reserved: 0,
>   commonattr: 0,
>   volattr: 0,
>   dirattr: 0,
>   fileattr: 0,
>   forkattr: attrgroup_t(ATTR_CMNEXT_PRIVATESIZE))
>   
>   let bufsize = 4 + MemoryLayout.size
>   let buf = UnsafeMutablePointer.allocate(capacity: bufsize)
>   defer { buf.deallocate(capacity: bufsize) }
>   
>   let err = url.withUnsafeFileSystemRepresentation { getattrlist($0, 
> &list, buf, bufsize, UInt32(FSOPT_ATTR_CMN_EXTENDED)) }
>   
>   if err != 0 { throw POSIXError.Code(rawValue: errno).map { 
> POSIXError($0) } ?? CocoaError(.fileReadUnknown) }
>   
>   let attrsize = buf.withMemoryRebound(to: UInt32.self, capacity: 1) { 
> $0.pointee }
>   
>   if attrsize < bufsize { throw CocoaError(.fileReadUnknown) }
>   
>   var unclonedSize: off_t = 0
>   
>   _ = withUnsafeMutableBytes(of: &unclonedSize) { memcpy($0.baseAddress!, 
> buf + 4, MemoryLayout.size) }
>   
>   return unclonedSize
> }
> 
> do {
>   let sourceURL = URL(fileURLWithPath: "/tmp/tempfile1")
>   let destURL = URL(fileURLWithPath: "/tmp/tempfile2")
> 
>   let sortaRandomData = Data(bytes: (0..<100 * 1024).map { 
> UInt8(extendingOrTruncating: $0) })
>   
>   try sortaRandomData.write(to: sourceURL)
>   
>   print("Uncloned size of source file: \(try unclonedSize(of: 
> sourceURL))")
>   
>   try FileManager.default.copyItem(at: sourceURL, to: destURL)
>   
>   print("Uncloned size of dest file: \(try unclonedSize(of: destURL))")
> } catch {
>   print("Error occurred: \(error.localizedDescription)")
> }
> 
> - - - - - - - - -
> 
> outputs:
> 
> Uncloned size of source file: 102400
> Uncloned size of dest file: 0
> 
> So, it seems quite clear that (NS)FileManager does, in fact, clone the files 
> you tell it to copy. :-)
> 
> Charles
> 


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Charles Srstka]

> On Jun 27, 2017, at 12:28 AM, Jens Alfke  wrote:
> 
>> On Jun 26, 2017, at 7:38 PM, Rick Mann > > wrote:
>> 
>> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
>> different from a clone.
> 
> The low level file copying API that I’m aware of is , which is 
> Apple specific. It has options for doing copy-on-write.
> I don’t know if NSFileManager’s copy method clones files. I would assume that 
> it does, on APFS.

Well, I mean, you could always *try* it ;-)

import Foundation

func unclonedSize(of url: URL) throws -> off_t {
var list = attrlist(bitmapcount: UInt16(ATTR_BIT_MAP_COUNT),
reserved: 0,
commonattr: 0,
volattr: 0,
dirattr: 0,
fileattr: 0,
forkattr: attrgroup_t(ATTR_CMNEXT_PRIVATESIZE))

let bufsize = 4 + MemoryLayout.size
let buf = UnsafeMutablePointer.allocate(capacity: bufsize)
defer { buf.deallocate(capacity: bufsize) }

let err = url.withUnsafeFileSystemRepresentation { getattrlist($0, 
&list, buf, bufsize, UInt32(FSOPT_ATTR_CMN_EXTENDED)) }

if err != 0 { throw POSIXError.Code(rawValue: errno).map { 
POSIXError($0) } ?? CocoaError(.fileReadUnknown) }

let attrsize = buf.withMemoryRebound(to: UInt32.self, capacity: 1) { 
$0.pointee }

if attrsize < bufsize { throw CocoaError(.fileReadUnknown) }

var unclonedSize: off_t = 0

_ = withUnsafeMutableBytes(of: &unclonedSize) { memcpy($0.baseAddress!, 
buf + 4, MemoryLayout.size) }

return unclonedSize
}

do {
let sourceURL = URL(fileURLWithPath: "/tmp/tempfile1")
let destURL = URL(fileURLWithPath: "/tmp/tempfile2")

let sortaRandomData = Data(bytes: (0..<100 * 1024).map { 
UInt8(extendingOrTruncating: $0) })

try sortaRandomData.write(to: sourceURL)

print("Uncloned size of source file: \(try unclonedSize(of: 
sourceURL))")

try FileManager.default.copyItem(at: sourceURL, to: destURL)

print("Uncloned size of dest file: \(try unclonedSize(of: destURL))")
} catch {
print("Error occurred: \(error.localizedDescription)")
}

- - - - - - - - -

outputs:

Uncloned size of source file: 102400
Uncloned size of dest file: 0

So, it seems quite clear that (NS)FileManager does, in fact, clone the files 
you tell it to copy. :-)

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Alastair Houghton]

On 27 Jun 2017, at 06:28, Jens Alfke  wrote:
> 
>> On Jun 26, 2017, at 7:38 PM, Rick Mann  wrote:
>> 
>> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
>> different from a clone.
> 
> The low level file copying API that I’m aware of is , which is 
> Apple specific. It has options for doing copy-on-write.
> I don’t know if NSFileManager’s copy method clones files. I would assume that 
> it does, on APFS.

That certainly seemed to be what the WWDC video suggested.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Jens Alfke]

> On Jun 26, 2017, at 7:38 PM, Rick Mann  wrote:
> 
> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
> different from a clone.

The low level file copying API that I’m aware of is , which is 
Apple specific. It has options for doing copy-on-write.
I don’t know if NSFileManager’s copy method clones files. I would assume that 
it does, on APFS.

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Sandor Szatmari]

> On Jun 26, 2017, at 22:45, Quincey Morris 
>  wrote:
> 
>> On Jun 26, 2017, at 19:17 , Sandor Szatmari  
>> wrote:
>> 
>> Are you talking about just a regular old copy or a copy in the sense of a 
>> time machine backup?  Are these behaviors different on APFS?
> 
> Yes and no. A regular old copy will create metadata for a new file, and point 
> back to the data blocks of the copied file. A time machine backup will create 
> a snapshot, which is effect a copy of all the metadata in the volume, with 
> the same shared pointers to the data blocks.

Yes, I felt the description of the copy on write behavior was intended to be 
universal to all copy operations not just a special operation reserved for time 
machine.  But, my even more admittedly vague understanding did not allow me to 
confidently draw a distinction be tween the two.  Thank you for tipping the 
scales.

> 
> In both cases, the functionality relies on the copy-on-write behavior, which 
> works at the data block level, not the file level.
Yes, this is very nice...
> (The latter point is worth keeping in mind, because it means that deleting 
> files in APFS may not recover all of the file’s size into free space.)
The ADC video stresses this point several times.

> 
>> On Jun 26, 2017, at 19:38 , Rick Mann  wrote:
>> 
>> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
>> different from a clone.
> 
> My (admittedly vague) understanding is that all file system copy operations 
> are expected to be clones. I would imagine the difference between the APIs to 
> be that a “copy" will do a traditional duplication if the source file is 
> uncloneable (e.g. on a non-APFS volume), but the “clone” would fail.
> 
> But it would be a big hole if existing apps that copy items didn’t get the 
> cloning behavior by default.
> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Quincey Morris]

On Jun 26, 2017, at 19:17 , Sandor Szatmari  
wrote:
> 
> Are you talking about just a regular old copy or a copy in the sense of a 
> time machine backup?  Are these behaviors different on APFS?

Yes and no. A regular old copy will create metadata for a new file, and point 
back to the data blocks of the copied file. A time machine backup will create a 
snapshot, which is effect a copy of all the metadata in the volume, with the 
same shared pointers to the data blocks.

In both cases, the functionality relies on the copy-on-write behavior, which 
works at the data block level, not the file level. (The latter point is worth 
keeping in mind, because it means that deleting files in APFS may not recover 
all of the file’s size into free space.)

On Jun 26, 2017, at 19:38 , Rick Mann  wrote:
> 
> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
> different from a clone.

My (admittedly vague) understanding is that all file system copy operations are 
expected to be clones. I would imagine the difference between the APIs to be 
that a “copy" will do a traditional duplication if the source file is 
uncloneable (e.g. on a non-APFS volume), but the “clone” would fail.

But it would be a big hole if existing apps that copy items didn’t get the 
cloning behavior by default.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Rick Mann]

I'm not talking about Time Machine. My code allows the user to duplicate data, 
and thus it duplicates the files o the disk. A lot of the files referenced by 
the model are immutable, and so a clone/lazy copy is ideal.

But there's actually a POSIX "clone" API, and so I wonder if a copy is 
different from a clone.

> On Jun 26, 2017, at 19:17 , Sandor Szatmari  
> wrote:
> 
> Are you talking about just a regular old copy or a copy in the sense of a 
> time machine backup?  Are these behaviors different on APFS?
> 
> The ADC video Quincey referred to a couple of weeks ago talked about 
> references to files being created (lazy copies).  Only when the blocks 
> associated with the newest reference are altered would any actual copying of 
> actual data be done.
> 
> Is this the behavior your referring to?
> 
> Sandor
> 
>> On Jun 26, 2017, at 21:34, Rick Mann  wrote:
>> 
>> If I use NSFileManager to make a copy on an APFS volume, will it make a 
>> clone underneath?
>> 
>> Is there a Cocoa API for cloning?
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
>> 
>> This email sent to admin.szatmari@gmail.com


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is cloning the same as copying in APFS?

[Sandor Szatmari]

Are you talking about just a regular old copy or a copy in the sense of a time 
machine backup?  Are these behaviors different on APFS?

The ADC video Quincey referred to a couple of weeks ago talked about references 
to files being created (lazy copies).  Only when the blocks associated with the 
newest reference are altered would any actual copying of actual data be done.

Is this the behavior your referring to?

Sandor

> On Jun 26, 2017, at 21:34, Rick Mann  wrote:
> 
> If I use NSFileManager to make a copy on an APFS volume, will it make a clone 
> underneath?
> 
> Is there a Cocoa API for cloning?
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Is cloning the same as copying in APFS?

[Rick Mann]

If I use NSFileManager to make a copy on an APFS volume, will it make a clone 
underneath?

Is there a Cocoa API for cloning?


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com