I'm using this method by Dave DeLong to calculate the size of a folder using the Carbon File Manager API:
http://github.com/davedelong/BuildCleaner/blob/b2712242b4eea1fff0e78a08b393a417e3019c8a/NSFileManager+FileSize.m
(Its the first method there)
The issue I'm having is that some folders (.app bundles in my case) are not reporting the correct size. For example, DiskWarrior is 8.2MB, and the method reports 6.6MB
Any ideas on why this is happening?
THANKS
I've improved on that source code of mine that you've linked to. Here's the newer version:
http://github.com/davedelong/BetterInfo/blob/aa1cfe079dad6207a7ddac84b108a768c2cc7156/NSFileManager+BetterInfo.m (You'll also need the corresponding .h file and this support file)
Now instead of returning and NSUInteger, it returns a struct of type "BIItemSyze", which has six members: dataLogicalSize, dataPhysicalSize, resourceLogicalSize, resourcePhysicalSize, logicalSize, and physicalSize.
The Finder will report file sizes rounded to the nearest multiple of the block size (usually 4 KB) followed by the real size in bytes, and many (most) applications are bundles of files, so the true size of the application may be far smaller than the size shown as the first ("on disk") value.
You can test this out by doing something (in the Terminal) like:
echo -n 'foo' > foo.txt
If you Get Info on this file in the Finder, it will report the size as "4 KB on disk (3 bytes)".
If you know how to use applescript's in your code, here's a method o return the size that you'd see in the Finder Get Info window. Note that the returned value is in bytes.
on getSizeInBytesFromPosixPath(posixPath)
try
set b to (POSIX file posixPath) as string
tell application "Finder" to return size of (b as alias)
on error
return 0
end try
end getSizeInBytesFromPosixPath
Related
TL;DR: can I do an incremental read of binary files with Red or Rebol?
I would like to use Red to process some large (13MB to 2GB) structured binary files (Kurzweil synthesizer files). I've used other languages (C, Go, Tcl, Ruby, Dart) to walk through these files, and now I'd like to do the same with Red or Rebol.
Is there a way to incrementally read binary files, byte by byte? All I see is read/binary which seems to slurp the entire file at once (or a part of a file).
I'll need to jump around a little bit, too (either peek at the next byte, or skip to the end of a section, or skip past variable length strings to the start of data).
(Yes, I could make some helpers that tracked the position and used read/part/seek.)
I would like to make a call to the low level OS read/seek if that is possible - something new to learn.
This is on macos, but a portable solution would be great.
Thanks!
PS: "open/read %abc" gives an error "*** Script Error: open does not allow file! for its port argument", even though the help message say the port argument is "port [port! file! url! block!]"
Rebol has ports for that, which are planned for 0.7.0 release in Red. So, current I/O is very basic and buffer-only, and open is a preliminary stub.
I would like to make a call to the low level OS read/seek if that is possible - something new to learn.
You can leverage Rebol or Red/System FFI as a learning excercise.
Here is how you would do it in Rebol:
>> file: open/direct/binary %file.dat
>> until [none? probe copy/part file 20]
>> close file
#{732F7072696E74657253657474696E6773312E62}
#{696E504B01022D00140006000800000021006149}
#{0910890100001103000010000000000000000000}
...
#{000000006A290000646F6350726F70732F617070}
#{2E786D6C504B0506000000000D000D0068030000}
#{292C00000000}
none
first file or pick file 1 will return the next byte value (integer!)
This even works with text files: open/lines/direct, in that case copy/part file 20 will return 20 lines, or you can use pick file 1 or first file to get the next line.
Soon this will be available on Red too.
I was trying to check the size of a file before I download it using renci.sshnet in vb.net. The only thing I notice is the .length always return a value of 4096 but the actual file is 700mb. Could someone help me get the accurate file size?
Dim sftpfile = sftp.ListDirectory("/Data/fdb")
For Each ftpFile In sftpfile
If FileSize > (i want to check those higher than 50mb) Then
'output file size
End If
Next
You need to get a reference to the file as an SftpFile object. Then you can access the size attribute. Here's how in C# (converting to VB.NET shouldn't be hard):
SftpFile file = sftpClient.Get(filePath);
return file.Attributes.Size;
What you're probably reading is the internal buffer size (4096) which you shouldn't worry about.
I just wrote a java class to generate meshes from a cylinder list stored to a ply file. I tested the files with a hand generated list of 3 cylinders. The resulting file I can open both in Meshlab and Cloudcompare.
When I use the class in my real program I have to write a mesh for more than 13000 cylinders.
Cloudcompare gives me the following error : Reading error(no access right?)
Meshlab this one : error details, unexptected eof
I already checked if my ply file contains the exact number of vertices and faces defined in the header. I also assured, there are no nan (checked for 'n','a', etc in winedit) values contained.
I can reproduce the errors with my test file from the 3 hand made cylinder file by deleting the last line. But as mentioned earlier, I already checked if the line numbers are correct (might be an empty line not caught by my eyes though, as scrolling down half a million lines is impossible).
So are there any programs available to parse the ply file for errors? Open source tools would be appreciated here. Or are the files just to large? 436302 lines to be exact. I use ascii version of ply.
Found a non open source tool called nugraf, which provides information about the corrupted line numbers.
Java seems to print NAN with '?'. For this char i did not check, so problem seems to be solved and I can debug my java software now again.
I have 7 files with extensions like xyz.rar.001 - xyz.rar.007 clearly they are parts of a single file. I have all the 7 parts. I join them using a file joiner into a single file xyz.rar and try to unrar them with WINRAR , it says that archive is corrupted It is clear that 1 or 2 parts are corrupted. IS THERE ANY WAY TO FIND THEM ? Please help I don't want to re download all of them NOTE- winrar can detect a corrupt part if the parts were splitted using winrar (with extensions like part1.rar , part2.rar etc. ) but not if they are named as rar.001
Parts .001 - .006 should have the same size. Check if there is a file with a different byte size.
Are there multiple files in the RAR or just the one? With multiple you could run a Test and see which is the first file to fail.
I think it's strange that there is a second tool used to split the RAR archive up. (e.g. HJSplit) This lets me think that .002 could be a RAR archive too. Try opening xyz.rar.001 with WinRAR and test/exctract. It happens more that RAR archives have the extension .001 instead of .rar. An example.
Naming your archives in WinRAR like this can be accomplished by putting "xyz.rar.001" as Archive name on the General tab and checking "Old style volume names" on the Advanced tab.
If I then join the files with HJSplit, I get one .rar file (that is corrupt). When I Test it, it says "Next volume is required". In the diagnostic messages I can see "The required volume is absent" and "CRC failed in X. The file is corrupt"
If there is one file stored inside the RAR and the RAR is indeed just chopped up into 7 pieces, there is no way of telling without additional files such as .sfv or .par2. (unless the RAR does not use compression: you can parse the underlying file for errors and calculate the part where it goes wrong)
I have a simple question, I suppose, but I cannot find anything.
What's the number at the end of line 6, + 429?
It means that the return address for stack frame 6 is 429 bytes past the start of the -[#### tableView:cellForRowAtindexPath:] function. It might be inside that function, or it might be past the end of the function but not inside any other known function.
UPDATE
In order for the symbolicator to turn those return addresses into line numbers, you must have the .dSYM file that the linker created when it created the executable file. Each executable is tagged with a UUID, and the .dSYM file is tagged with the same UUID. The symbolicator looks at the UUID of the executable and uses Spotlight (OS X's filesystem search support) to find the matching .dSYM. If you didn't save the .dSYM, you will have a hard time turning the addresses into line numbers. Note that when you tell Xcode to build an archive (Product > Archive), the archive contains both the executable and its matching .dSYM.