The information may be irrelevant and/or useless, but it is available for file
systems that support it (HFS+ does). Although, I think it may require
super-user privileges to query.
$ man fcntl
…
F_LOG2PHYS Get disk device information. Currently this
only includes the disk device address
that corresponds to the current
file offset.
F_LOG2PHYS_EXT Variant of F_LOG2PHYS that uses the passed in
file offset and length.
...
-Ed
On Apr 8, 2014, at 11:48 AM, Maxthon Chan <xcvi...@me.com> wrote:
> Concerning if a file is fragmented is sort of useless, I think. Modern
> filesystem APIs does not even expose details of that, and the only way I now
> how to find out about that, is to roll your own HFS+ driver (or whatever
> filesystem you are concerning) and access raw bock devices (e.g. /dev/disk0)
> yourself. If that is the situation you may want to move your project to Linux
> as there are 3rd party libraries designed to allow you access on that level,
> with proper kernel support and using existing filesystem drivers, but that is
> limited to Linux.
>
> If you are regarding execution speed you should disregard. All your users who
> is using a Mac that is less than one year old is very likely to be equipped
> with solid state drive which have no seek time. Not too many Mac users I know
> still hog onto a three-year-old MacBook Pro with spinning platters now. (I
> was even mocked by my ex-colleagues that I quit before the company gave
> everyone MacBook Pros with SSD in them)
>
> On Apr 8, 2014, at 22:53, Fritz Anderson <fri...@manoverboard.org> wrote:
>
>> On 8 Apr 2014, at 9:19 AM, Nick Rogers <roger...@mac.com> wrote:
>>
>>> I just need to know, if a file is fragmented or not. I don’t need the frags
>>> details etc.
>>> Its for showing extended info about the selected file, like whether it is
>>> fragmented or not.
>>>
>>> Is it possible with out raw reading the volume (for its catalog file)?
>>>
>>> I have also seen Carbon File Manager’s FSGetCatalogInfo() and fstat() and
>>> they don’t return this info.
>>
>> I agree that it’s an implementation detail of the filesystem, and in any
>> event not a matter for a Cocoa discussion list.
>>
>> In a modern file system, physical storage of files is either meaningless, or
>> always (three-nines) fragmented, barring first write on a virgin disk.
>>
>> — F
>>
>>
>> _______________________________________________
>>
>> 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/xcvista%40me.com
>>
>> This email sent to xcvi...@me.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/arwyn%40phasic.com
>
> This email sent to ar...@phasic.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
