Re: read() slower than write() on the same disk

The fs_usage command line tool will show you a lot. In particular, look at the TIME INTERVAL(W) column. > On Nov 6, 2014, at 6:42 AM, Dragan Milić wrote: > > Hi everyone, > > This is rather long message, but I tried to describe my problem in details so > that it may be easier to provide expl

Re: Virtual hard drive

It might take you less time to add server support for an existing protocol than it will to write and test a VFS file system plugin. Another plus is that if you pick a protocol supported by multiple operating systems (like SMB), you widen your market. - Jim > On Nov 29, 2014, at 8:56 AM, George

Re: readdir vs. getdirentriesattr

And to clarify... readdir may be faster than getattrlistbulk if all you need are the names. If you call getattrlist (or lstat) on every item you get back from readdir, you'll find that getattrlistbulk is faster. - Jim > On Dec 10, 2014, at 4:57 PM, Eric Tamura wrote: > > It should be much fas

Re: readdir vs. getdirentriesattr

getattrlistbulk() works on all file systems. If the file system supports bulk enumeration natively, great! If it does not, then the kernel code takes care of it. In addition, getattrlistbulk() supports all non-volume attributes (getattrlistbulk only supported a large subset). The API calling co

Re: readdir vs. getdirentriesattr

In Yosemite (10.10), Carbon's PBGetCatalogInfoBulk and directory enumerators created with CoreFoundation's CFURLEnumerator (it's in CFURLEnumerator.h, not CFURL.h) both use getattrlistbulk() instead of readdir() or getdirentriesattr(). Foundation API like- [NSFileManager contentsOfDirectoryAtUR

Re: Testing the 2TB file size limit

I don't know that the file system APIs on OSX/iOS support files larger than LONG_LONG_MAX since they use a signed-64 bit value for offsets. Assuming a file system supports it, pathconf(path, _PC_FILESIZEBITS) would be the correct way to determine the maximum file size in bits. _PC_FILESIZEBITS

Re: Determine whether a NFS mount is actually reachable

At the Carbon/CoreFoundation/Foundation layer and above, OSX presents the illusion that once mounted, automounted volumes are always mounted. They are not removed from the volume list if they are auto-unmounted because FSRefs and file reference URLs (which refer to volumes by ID) held by existin

Re: Filesystem path that works even after a dir is moved?

> On Nov 3, 2015, at 12:19 AM, Quinn The Eskimo! wrote: > > > On 2 Nov 2015, at 19:59, Jens Alfke wrote: > >> Now, FSRefs aren’t paths but they also have the property that they work even >> when a directory is moved. I dimly remember from the early days of OS X that >> there was a form of pa

Re: FSEventStream and rename notifications

> On Mar 6, 2016, at 5:04 PM, James Bucanek wrote: > > >> tridiak March 5, 2016 at 9:14 PM >> >> >> I want a way to know a file what a file’s new name is. >> Having event ID X (old name) & X+1 (new name) for file rename (& move) would >> be really useful. >> >> I

Re: FSEventStream and rename notifications

> On Mar 7, 2016, at 10:29 AM, Thomas Tempelmann wrote: > > On Mon, Mar 7, 2016 at 7:04 PM, James Bucanek > wrote: > That is, I can create a bookmark for a file, rename/move that file, and the > bookmark will still find it. > > A problem only comes up when the u

Re: Network Trash

Apple doesn't support trash directories (or temporary item directories) on network volumes and hasn't for quite a while because there is no good mechanism to clean up trash on network volumes (i.e., if a user mounts a network volume, moves files to the trash, unmounts the network volume, and nev

Re: Network Trash

aviour I could implement in my own filesystem? Lots of things are special-cased for iCloud Drive. > > -- > Charles Francoise > Lead Mac Developer @ Lima > char...@meetlima.com > > > > > > >> On 12 Apr 2016, at 18:05, Jim Luther wrote: >> >

Re: CFURLWriteBookmarkDataToFile fails with Alias records

Hi Thomas, This sentence in the header file comment (which should be in the documentation but isn't) explains the problem. > The bookmark data must have been created with the > kCFURLBookmarkCreationSuitableForBookmarkFile option. The bookmark data created by CFURLCreateBookmarkDataFromAliasRe

Re: Slow directory browsing in OS X10.11, was fast on 10.6.

Hi Thomas, 10.6 or 10.7 to 10.11 is a big jump with lots of changes. If you could hone it down to which major release the performance regression occurred (it might have been in 10.8, 10.9, or 10.10), it would help. Also, an Instruments Time Profiler trace including kernel callstacks should sho

Re: APFS questions

> On Jun 30, 2016, at 6:49 PM, tridiak wrote: > > Some questions concerning APFS Have you looked at an APFS file system in the WWDV seed? Have you watched the WWDC presentation? Those would answer a lot of your questions. > - My guess is resource forks are being dropped. What will happen to t

Re: Time Machine's volume uuid -- what does it match against?

This is a guess, but have you looked at the NSURLVolumeUUIDStringKey returned by -[NSURL getResourceValue:forKey:error:] (or the kCFURLVolumeUUIDStringKey property returned by CFURLCopyResourcePropertyForKey()). It should be the UUID for the volume. > On Jul 20, 2016, at 10:03 AM, Jim O'Connor

Re: SMB and ACLs

I'm guessing TextEdit is using NSURLIsWritableKey like this: NSURL *url = [NSURL fileURLWithPath:@"/System/" isDirectory:YES]; // "/System/" isn't writable for most users NSError *error; NSNumber *isWritable = nil; if ( [url getResourceValue:&isWritable forKey:NSUR

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

As -[NSURL getResourceValue:forKey:error:] is documented, "If this method returns YES and the value is populated with nil, it means that the resource property is not available for the specified resource, and that no errors occurred when determining that the resource property was unavailable." So

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

Scott, if you walk through that code, do you see which path it's getting a value from -- pathconf or getattrlist? The code in our frameworks that gets that value runs when a file system is first mounted. We have code listening for kNotifyVFSMount BSD notifications. When a notification comes in,

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

kernel event and that's what causes the kNotifyVFSMount BSD notification to be sent. At that time, file systems must be ready to respond to requests correctly. If they don't, they have a bug. - Jim > On Sat, 1 Apr 2017, Jim Luther wrote: > >> Scott, if you walk through that code, d

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

> the FUSE kext thus far. It seems to be setting VOL_CAP_FMT_2TB_FILESIZE >> when it should be. >> >> On Mon, 3 Apr 2017, Jim Luther wrote: >> >>> >>> On Apr 3, 2017, at 8:56 AM, Scott Talbert >>> wrote: >>> It's get

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

rror message? My > hunch has been that it is related to the NSURL result, but strangely, we only > see this Finder error consistently on one specific machine. > > On Wed, 5 Apr 2017, Jim Luther wrote: > >> No. Immutable properties and capabilities like NSURLVolumeMaximumFileSiz

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

(trying again with most of the history removed -- it hit a mailing list size limit) The same code that calculates the maximum file size runs on all file systems -- local or not -- as soon as a file system is seen. My theory is the same as it was before: > On Apr 3, 2017, at 10:30 AM,

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

I removed this check, things work correctly. > > Now, I still don't understand why coreservicesd isn't falling back to > getattrlist() when the pathconf() request fails. Perhaps depending on the > type of error from pathconf(), it doesn't go further to getattrlist()? &

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

coreservicesd might be doing something different based on the >> errno, but it sounds like it is not. >> >> On Fri, 14 Apr 2017, Jim Luther wrote: >> >>> Maybe FUSE is blocking more than pathconf(). That's not my code to debug. >>> And yes, corese

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

gt; The problem is, this Finder error is only reproducible on two machines, out >> of perhaps several dozen using this filesystem. So, unfortunately, I don't >> have a set of easy steps to reproduce. >> >> On Fri, 14 Apr 2017, Jim Luther wrote: >> >>> A

Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

work around this. In particular, I'm interested in the specific > conditions under which coreservicesd does not ask for the file system’s > capabilities. It would be very helpful if you could share your findings. > > Thanks, > Benjamin > >> Am 15.04.2017 um 23:34 schr

Re: searchfs support on APFS

FSCatalogSearch is part of the deprecated Carbon File Manager API. The Carbon File Manager API exposes file IDs and directory IDs as 32-bit values and so FSCatalogSearch will never be supported on APFS (which use 64-bit file IDs and directory IDs). In 10.13: • PBCatSearch on APFS volumes will r

Re: from sidebar to NSURLDocumentIdentifierKey

As things work today... When a user drags a file system volume out the Devices sidebar list, the Visibility is set to NeverVisible for that device in the list (as you can see below). The Bookmark is a URL bookmark object (serialized) used to determine which file system volume should be hidden i

Re: from sidebar to NSURLDocumentIdentifierKey

byte chars. So it > is curious that the working HFS somehow ends up with 2 byte chars. > > When trying to parse the Alias data, it will fail as the string length 36, > being longer than the rest of the data, presumably because the length 18 > (0x12) as been doubled in anticipation of

Re: So what does VOL_CAP_INT_USERACCESS actually mean?

Here's something that is kind of related that I ran into recently. If you have code that is checking the ownership and permissions of a file system object and attempting to correct the ownership and permissions if it is wrong, don't bother if the MNT_IGNORE_OWNERSHIP mount flag is set -- nothing

Re: readdir vs. getdirentriesattr

9/04/dir-read-performance.html> > > There's also a test project trying out the various methods. > > Any comments, insights, clarifications and bug reports are most welcome. > > Enjoy, > Thomas Tempelmann > > >> On 12. Jan 2015, at 17:33, Jim Luthe

Re: readdir vs. getdirentriesattr

I don’t really have time to look at the current fts implementation, but… it has several options that effect performance (in particular, the FTS_NOCHDIR, FTS_NOSTAT, FTS_NOSTAT_TYPE, and FTS_XDEV options). If you are trying to compare fts to CFURLEnumerator (for example), use FTS_NOCHDIR and FTS_

Re: readdir vs. getdirentriesattr

In contentsOfDirectoryAtURL, instead of "includingPropertiesForKeys:nil", use "includingPropertiesForKeys:@[NSURLVolumeIdentifierKey]" (and add whatever other property keys you know you'll need). The whole purpose of the includingPropertiesForKeys argument is so the enumerator code can pre-fetch

Re: readdir vs. getdirentriesattr

> On Apr 29, 2019, at 1:19 PM, Thomas Tempelmann wrote: > > Jim, > > In contentsOfDirectoryAtURL, instead of "includingPropertiesForKeys:nil", use > "includingPropertiesForKeys:@[NSURLVolumeIdentifierKey]" (and add whatever > other property keys you know you'll need). The whole purpose of th