[swift-corelibs-dev] Opinions wanted: Special Handling of /proc FileSystem on Linux?

[Philippe Hausler]

IMHO it seems reasonable for Foundation to return the contents of procfs items when constructing Data. That being said - I would probably favor a more structured parsing for actually using that resultant Data than just a blob. Those structured elements are probably not very portable so perhaps they belong in something above Foundation. 

I don’t know of any linux variants off hand that don’t have /proc, but it might be interesting to somehow detect if that is truly a procfs element. I think it would perhaps be a failure if just the path /proc is special cased; Android, Solaris and Plan9 also share this same concept iirc (there are likely others).

> On Jan 12, 2017, at 11:40 AM, Carl Brown1 via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> Hi,
> 
> I run the Austin Swift meetup group, and a question came up about the /proc filesystem on Linux:
> 
> The question involved the inability to get any useful information from Data(contentsOf: URL(fileURLWithPath: "/proc/sys/fs/file-max")).
> 
> It turns out that Data(contentsOf:) does a stat() on the inode of the file you give it, and then runs alloc()/read() for the specified number of bytes. This works fine on normal files on normal file systems. But all the files in /proc have a 0 length specified by their inodes, and you have to actually read them until EOF to find out how much is there.
> 
> So the question is: Is that something the *Programmer* should be responsible for knowing, or should *Foundation* be responsible for handling that correctly?
> 
> I can see a case that we'd want to avoid embedding things this OS-specific in Foundation, but on the other hand, I know that this is very confusing for Darwin developers moving to Linux and expecting Data(contentsOf:) to "Just work."
> 
> So I thought I'd ask the community and see if there was a consensus.
> 
> Thanks,
> 
> -Carl
> 
> -- 
> Carl Brown
> Swift at IBM
> Carl.Brown1 at IBM.com
> 
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20170112/fa55fdab/attachment.html>