Re: Determine whether a NFS mount is actually reachable

2015-02-22 Thread Thomas Tempelmann
I did some testing and can confirm that what Jim wrote below only tells me whether a path has an auto-mount trigger, but not whether it's actually reachable at the moment. So far, to tell if the volume is actually available I must try to read its content. Often I would then get an error returned

Strategie for detecting changes to remote network files

2016-08-09 Thread Thomas Tempelmann
OSX notify me when the user on this Mac makes changes to files on the network volume? (Meaning I could detect changes made by the user without polling, while I'd still need to poll to detect changes made from other computers?) Any advice and insights are appreciated. -- Thomas Tempelmann, http

How do I lock a volume the way First Aid does?

2017-03-26 Thread Thomas Tempelmann
repair it. How does DFA do that? Is there some OS function I could use for that purpose, too? -- Thomas Tempelmann, http://www.tempel.org/ Follow me on Twitter: https://twitter.com/tempelorg Read my programming blog: http://blog.tempel.org/ ___ Do

New Disk Utility apparently not using rdisk when saving / restoring partitions

2017-03-31 Thread Thomas Tempelmann
e with "dd" and "rdisk", I got to the maximum, which was about 200 MB/s. That's more than five times slower than it should be. I'm going to write a blog article about this over the weekend, too. -- Thomas Tempelmann, http://www.tempel.org/ Follow me on Twitter: https://tw

Re: Updated APFS guide

2017-03-31 Thread Thomas Tempelmann
On Sat, Apr 1, 2017 at 1:32 AM, Brendan Shanks wrote: > The Apple File System Guide was updated yesterday with additional info > about filenames, iOS 10.3, and macOS 10.12.4. Quick summary: no > normalization, iOS 10.3 is case-sensitive, 10.12.4 now has (beta) >

Re: searchfs support on APFS

2017-07-06 Thread Thomas Tempelmann
I was kindly informed that 10.12 already supports searchfs (and FSCatalogSearch along with it) on APFS, and after doing some testing myself it turned out that it's all working as intended, and that I just did the testing wrong, on my misguided assumptions, along with using an outdated version of

Re: searchfs support on APFS

2017-07-25 Thread Thomas Tempelmann
cannot learn about the separate dir entries of multiple hard links* to the same file. (https://openradar.appspot.com/33473247) I've also got a blog post about this here: http://blog.tempel.org/2017/07/apfs-and-fast-catalog-search.html -- Thomas Tempelmann, http://www.tempel.org/ Follow me

searchfs support on APFS

2017-07-06 Thread Thomas Tempelmann
this in as early as possible, but I'll make sure to file a bug report should my suspicion be confirmed). -- Thomas Tempelmann, http://www.tempel.org/ Follow me on Twitter: https://twitter.com/tempelorg Read my programming blog: http://blog.tempel.org/ ___ Do

Re: gmtime_r bug in High Sierra?

2017-09-10 Thread Thomas Tempelmann
Disregard my previous post. I did some testing on my own and believe it was just a user (programming) error. My apologies for the unnecessary alertism. Thomas ___ Do not post admin requests to the list. They will be ignored. Filesystem-dev mailing

Re: gmtime_r bug in High Sierra?

2017-09-10 Thread Thomas Tempelmann
With this comment, I'll cross-post this to the filesystem-dev list, as this could be a bug in the APFS code, making this a bit urgent with the imminent release of 10.13 But it could also be that there's a new(?) flag somewhere that you need to test in order to tell whether the values are in

Re: APFS root filesystem. All files' inode id have offset of 0x200000000

2018-03-22 Thread Thomas Tempelmann
Eric, What information are you trying to get out of each scan? You will always > have a time-of-use vs. time-of-check race condition here .. the filesystem > is in a perennial state of flux. > That's one thing I was surprised about when using searchfs() on APFS vs. HFS+: On HFS, I'd frequently

Re: APFS root filesystem. All files' inode id have offset of 0x200000000

2018-03-22 Thread Thomas Tempelmann
> > So far I hadn't had much lack in scanning by this order, sparse filesystem > makes the /.vol// option inefficient. > As for the searchfs option, I haven't seen in the man page any way to > control the order of the files. > The order is arbitrary, as it walks over the btree nodes in the most

Re: APFS root filesystem. All files' inode id have offset of 0x200000000

2018-03-21 Thread Thomas Tempelmann
> > 1. Is there any way to extract the current file-id range (minimum to > maximum fileid). > Well, both HFS+ and APFS know the last used FileID and whenever a new node (file, dir) is created, the last ID + 1 will be used for it. But you cannot query that value directly (only indirectly, by

Re: FSEvents API and sandboxing

2019-05-16 Thread Thomas Tempelmann
On Thu, May 16, 2019 at 7:43 PM Dominic Giampaolo wrote: > > > Without knowing the particulars about sandboxing, I wonder why you > originally wanted to use multiple streams anyway. I had thought it's > obvious that using multiple streams for watching multiple locations would > be rather

Re: FSEvents API and sandboxing

2019-05-15 Thread Thomas Tempelmann
Without knowing the particulars about sandboxing, I wonder why you originally wanted to use multiple streams anyway. I had thought it's obvious that using multiple streams for watching multiple locations would be rather inefficient compared to having only one watcher for "/", and then filter the

Re: readdir vs. getdirentriesattr

2019-04-29 Thread Thomas Tempelmann
Doing more performance tests for directory traversal I ran into a performance issue with [NSURL contentsOfDirectoryAtURL:]: See this typical code for scanning a directory: NSArray *contentURLs = [fileMgr contentsOfDirectoryAtURL:parentURL includingPropertiesForKeys:nil options:0 error:nil];

Re: readdir vs. getdirentriesattr

2019-04-29 Thread Thomas Tempelmann
value without time penalty, unlike contentsOfDirectoryAtURL. Regardless, I'll give that a try. -- Thomas Tempelmann, http://apps.tempel.org/ Follow me on Twitter: https://twitter.com/tempelorg Read my programming blog: http://blog.tempel.org/ ___ Do no

Re: readdir vs. getdirentriesattr

2019-04-29 Thread Thomas Tempelmann
Quick update: > -[enumeratorAtURL:includingPropertiesForKeys:options:errorHandler:] also >> supports recursive enumeration (which stops at device boundaries -- you'll >> see mount points but not their contents) so you don't have to do that >> yourself. >> > This is indeed faster than most of the

Re: readdir vs. getdirentriesattr

2019-04-29 Thread Thomas Tempelmann
> The volume ID is at a higher layer, but the enumeration code attempts to > retrieve the value less than once per URL returned. That said, if the > directory hierarchy has few items per directory, the number of times it is > retrieved will be higher. You can write a bug report and I'll look to

Re: APFS cloning not working across volumes inside same container?

2019-05-06 Thread Thomas Tempelmann
> > The think that most closely resembles the HFS catalog isn't shared amongst > volumes. But it is. There is one btree for all volumes in a container (well, technically, there are two btrees, one for the IDs and one for the actual file catalog, but both are shared over all vols). >

Re: APFS cloning not working across volumes inside same container?

2019-05-07 Thread Thomas Tempelmann
Hi Dominic, Thank you for jumping in. I accept that it's currently not possible - but just to help me understand this, could you please elaborate: In theory, would it be possible to share a cloned file between two volumes? Since they're in the same container, and the space management is

Re: APFS cloning not working across volumes inside same container?

2019-05-07 Thread Thomas Tempelmann
That makes sense to me. Thank you for taking the time to explain. Thomas On Tue, May 7, 2019 at 4:33 PM Dominic Giampaolo wrote: > > > I accept that it's currently not possible - but just to help me > understand this, could you please elaborate: > > > > In theory, would it be possible to

APFS cloning not working across volumes inside same container?

2019-05-06 Thread Thomas Tempelmann
wonder if that's just a shortcoming of the Finder or a problem with the macOS API. After all, since APFS shares a single catalog between all volumes of its container, cloning should be possible across volumes, shouldn't it? -- Thomas Tempelmann, http://apps.tempel.org/ Follow me on Twitter: https

Re: readdir vs. getdirentriesattr

2019-04-21 Thread Thomas Tempelmann
ethods. Any comments, insights, clarifications and bug reports are most welcome. Enjoy, Thomas Tempelmann > On 12. Jan 2015, at 17:33, Jim Luther wrote: > > getattrlistbulk() works on all file systems. If the file system supports bulk > enumeration natively, great! If it does no

Re: readdir vs. getdirentriesattr

2019-04-22 Thread Thomas Tempelmann
Jim, thanks for your comments. If all you need is filenames and no other attributes, readdir is usually > faster than getattrlistbulk because it doesn't have to do as much > work. However, if you need additional attributes, getattrlistbulk is > usually much faster. Some of that extra work done >

searchfs on Catalina - trouble with split system vs user volume

2019-06-04 Thread Thomas Tempelmann via Filesystem-dev
is, i.e. how I can search both the system and the user volumes with searchfs? How do I determine and address them? -- Thomas Tempelmann, http://apps.tempel.org/ ___ Do not post admin requests to the list. They will be ignored. Filesystem-dev mai

Re: searchfs on Catalina - trouble with split system vs user volume

2019-06-07 Thread Thomas Tempelmann via Filesystem-dev
a separate searchfs() on that extra volume. Thanks for the quick help (which I got in a private email)! Thomas > On 4. Jun 2019, at 21:20, Thomas Tempelmann wrote: > > The new system splits up the boot volume into a user's and the system's > volume, somehow. The problem is now tha

Rare bug in HFS path conversion function involving slashes in folder names

2019-09-18 Thread Thomas Tempelmann via Filesystem-dev
Just a small heads-up when you still have to deal with HFS paths: Getting the HFS Path from an NSURL using CFURLCopyFileSystemPath (path, 1) does not work if the path contains a file that uses a "/" (or ":", respectively) in its name. Filed as FB7291855, see also

Re: APFS: mmap page fault can take up to minutes after ftruncate/F_PREALLOCATE

2019-12-19 Thread Thomas Tempelmann via Filesystem-dev
Out of curiosity, I just ran the test on my 10.13.6 system: On HFS+, the tool finishes in about 5 seconds, ending up with a 4 GB file. However, on a freshly created APFS vol (no encryption, on same SSD as the HFS+ volume), it runs for about an hour! But no extra wait time around 2 GB. I guess