headers
Bryan Lund | 1 Jul 2003 01:28
Picon

Getting the "real" size of a file

I am attempting to get the size of a file using something akin to the 
following :

NSNumber *fsize;
NSFileManager *manager = [[NSFileManager alloc] init];
NSDictionary *fattrs = [manager fileAttributesAtPath:[ <at> "path to file"] 
traverseLink:NO];
fsize = [fattrs objectForKey:NSFileSize];

However NSFileSize returns the file size that you get when you do an 
"ls -l" in the terminal...not the file size as reported by the Finder.  
Oftentimes these sizes are quite different.

Is there any way to retrieve the file size for a file so that it 
matches what is seen in the Finder?

Thanks!
-Bryan
Permalink | Reply | 7 comments |
headers
Creed Erickson | 1 Jul 2003 03:13
Picon

Re: Getting the "real" size of a file

What you are getting will be the file size except for 2 cases: Files 
with resource forks, and bundles (e.g.: apps). In the first case you 
need to add the size of "filename" and "._filename" to get the right 
file size. For bundles, you need to traverse the bundle directory 
structure summing all sizes.

On Monday, June 30, 2003, at 04:28 PM, Bryan Lund wrote:

> I am attempting to get the size of a file using something akin to the 
> following :
>
> NSNumber *fsize;
> NSFileManager *manager = [[NSFileManager alloc] init];
> NSDictionary *fattrs = [manager fileAttributesAtPath:[ <at> "path to file"] 
> traverseLink:NO];
> fsize = [fattrs objectForKey:NSFileSize];
>
> However NSFileSize returns the file size that you get when you do an 
> "ls -l" in the terminal...not the file size as reported by the Finder. 
>  Oftentimes these sizes are quite different.
>
> Is there any way to retrieve the file size for a file so that it 
> matches what is seen in the Finder?
>
> Thanks!
> -Bryan
---
Creed Erickson <creed@...>
"Not a shred of evidence exists in favor of the idea that life is 
serious."
(Continue reading)

Permalink | Reply | 6 comments |
headers
Chad Leigh -- ObjectWerks Inc. | 1 Jul 2003 03:24

Re: Getting the "real" size of a file

Hi

I think what he wants is the size the Finder reports which is based on 
how many blocks the file uses.  Ie, a file that is 1 byte still shows 
as 4k or whatever it is on a modern HFS+ disk.  I don't think he is 
looking for the actual file size in bytes...

Chad

On Monday, Jun 30, 2003, at 19:13 US/Mountain, Creed Erickson wrote:

> What you are getting will be the file size except for 2 cases: Files 
> with resource forks, and bundles (e.g.: apps). In the first case you 
> need to add the size of "filename" and "._filename" to get the right 
> file size. For bundles, you need to traverse the bundle directory 
> structure summing all sizes.
>
>
> On Monday, June 30, 2003, at 04:28 PM, Bryan Lund wrote:
>
>> I am attempting to get the size of a file using something akin to the 
>> following :
>>
>> NSNumber *fsize;
>> NSFileManager *manager = [[NSFileManager alloc] init];
>> NSDictionary *fattrs = [manager fileAttributesAtPath:[ <at> "path to 
>> file"] traverseLink:NO];
>> fsize = [fattrs objectForKey:NSFileSize];
>>
>> However NSFileSize returns the file size that you get when you do an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Peciva | 1 Jul 2003 03:27
Picon

Re: Getting the "real" size of a file

There is also the difference that ls -l will tell you how many bytes 
are in the file, but Finder will tell you how many bytes the file takes 
up on disk. Actual file sizes typically come in 4k increments 
(depending on the size of the disk), so you will almost always get a 
small discrepancy.

Cheers,
Tobias Peciva
Pharos Systems

On Tuesday, July 1, 2003, at 01:13  PM, Creed Erickson wrote:

> What you are getting will be the file size except for 2 cases: Files
> with resource forks, and bundles (e.g.: apps). In the first case you
> need to add the size of "filename" and "._filename" to get the right
> file size. For bundles, you need to traverse the bundle directory
> structure summing all sizes.
>
>
> On Monday, June 30, 2003, at 04:28 PM, Bryan Lund wrote:
>
>
>> I am attempting to get the size of a file using something akin to the
>> following :
>>
>> NSNumber *fsize;
>> NSFileManager *manager = [[NSFileManager alloc] init];
>> NSDictionary *fattrs = [manager fileAttributesAtPath:[ <at> "path to file"]
>> traverseLink:NO];
>> fsize = [fattrs objectForKey:NSFileSize];
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Parker | 1 Jul 2003 03:38
Picon
Favicon

Re: Getting the "real" size of a file

(I'm editing this a little so I can have both the code as presented and 
the reply in sequence)

On Monday, June 30, 2003, at 6:13 PM, Creed Erickson wrote:

> On Monday, June 30, 2003, at 04:28 PM, Bryan Lund wrote:
>
>> I am attempting to get the size of a file using something akin to the 
>> following :
>>
>> NSNumber *fsize;
>> NSFileManager *manager = [[NSFileManager alloc] init];
>> NSDictionary *fattrs = [manager fileAttributesAtPath:[ <at> "path to 
>> file"] traverseLink:NO];
>> fsize = [fattrs objectForKey:NSFileSize];
>>
>> However NSFileSize returns the file size that you get when you do an 
>> "ls -l" in the terminal...not the file size as reported by the 
>> Finder.  Oftentimes these sizes are quite different.
>>
>> Is there any way to retrieve the file size for a file so that it 
>> matches what is seen in the Finder?
>>
>> Thanks!
>> -Bryan
> What you are getting will be the file size except for 2 cases: Files 
> with resource forks, and bundles (e.g.: apps). In the first case you 
> need to add the size of "filename" and "._filename" to get the right 
> file size.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gerd Knops | 1 Jul 2003 04:14
Favicon

Re: Getting the "real" size of a file


On Monday, Jun 30, 2003, at 20:38 US/Central, Chris Parker wrote:

> (I'm editing this a little so I can have both the code as presented 
> and the reply in sequence)
>
> On Monday, June 30, 2003, at 6:13 PM, Creed Erickson wrote:
>
>> On Monday, June 30, 2003, at 04:28 PM, Bryan Lund wrote:
>>
>>> I am attempting to get the size of a file using something akin to 
>>> the following :
>>>
>>> NSNumber *fsize;
>>> NSFileManager *manager = [[NSFileManager alloc] init];
>>> NSDictionary *fattrs = [manager fileAttributesAtPath:[ <at> "path to 
>>> file"] traverseLink:NO];
>>> fsize = [fattrs objectForKey:NSFileSize];
>>>
>>> However NSFileSize returns the file size that you get when you do an 
>>> "ls -l" in the terminal...not the file size as reported by the 
>>> Finder.  Oftentimes these sizes are quite different.
>>>
>>> Is there any way to retrieve the file size for a file so that it 
>>> matches what is seen in the Finder?
>>>
>>> Thanks!
>>> -Bryan
>> What you are getting will be the file size except for 2 cases: Files 
>> with resource forks, and bundles (e.g.: apps). In the first case you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bryan Lund | 1 Jul 2003 06:24
Picon

Re: Getting the "real" size of a file


On Monday, June 30, 2003, at 6:38 PM, Chris Parker wrote:
>
>>>
>>> Is there any way to retrieve the file size for a file so that it 
>>> matches what is seen in the Finder?
>>>
>> What you are getting will be the file size except for 2 cases: Files 
>> with resource forks, and bundles (e.g.: apps). In the first case you 
>> need to add the size of "filename" and "._filename" to get the right 
>> file size.
>
> You really need to be careful about this - the ._filename case is only 
> on systems that don't support resource forks (e.g., NFS, SMB). 
> Arguably, the NSFileSize attribute should return the combined size of 
> both the resource fork and the data fork (there's a bug on this 
> already).
>
> You can't rely on a ._ file existing everywhere; in fact, you probably 
> shouldn't rely on it existing at all.
>

What method would you recommend for this?  Obviously many apps do this 
(Finder in 10.3 jumps to mind)...but what is the "right" way?

-Bryan
Permalink | Reply | 1 comment |
headers
Scott Anguish | 1 Jul 2003 07:01

Re: Getting the "real" size of a file


On Tuesday, July 1, 2003, at 12:24 AM, Bryan Lund wrote:

>> You really need to be careful about this - the ._filename case is 
>> only on systems that don't support resource forks (e.g., NFS, SMB). 
>> Arguably, the NSFileSize attribute should return the combined size of 
>> both the resource fork and the data fork (there's a bug on this 
>> already).
>>
>> You can't rely on a ._ file existing everywhere; in fact, you 
>> probably shouldn't rely on it existing at all.
>>
>
> What method would you recommend for this?  Obviously many apps do this 
> (Finder in 10.3 jumps to mind)...but what is the "right" way?
>

	The thing about the Finder doing it is that they can ensure that any 
change (like ._ going away) is taken into account.  You won't run the 
10.3 finder on a 10.2 system and expect it to work.
Permalink | Reply | 0 comments |
headers
Scott Anguish | 1 Jul 2003 07:03

Re: Center TableView Text


On Sunday, June 29, 2003, at 8:34 AM, Mark Davis wrote:

> I want to know how to VERTICALLY center tableview text, I have my row 
> height set to 32 and it doesn't look good when the text is stuck to 
> the top.
>

	You could make your own cell and use it.

	Mind you, you probably don't want it vertically centered.. because 
"this" and "goo" will line up differently visually.  You probably want 
baseline to fiddle with the positioning relative to the baseline.
Permalink | Reply | 0 comments |
headers
Ken McGaugh | 1 Jul 2003 08:51
Picon
Favicon

reordering windows

Hello,

I would like to write a tool for OSX which would allow me to change the 
stacking
order of windows (across applications) without changing which window has the
actual focus.

Is this possible, and if so could someone please give me a hint where to 
begin
reasearching this?

Many thanks.
--Ken

_________________________________________________________________
Need more speed?  Get Xtra Jetstream  <at>   
http://www.xtra.co.nz/products/0,,5803,00.html !
Permalink | Reply | 0 comments |

Gmane