Sys-filesystem interface advice

Hi,

I’m going to add the Filesystem.mount_point method. It will simply
return the mount point associated with the given file.

Example:

Filesystem.mount_point(’/home/djberge/foo.txt’) # => ‘/home’ (RHEL
Linux)

My dilemma is what I should do when I can’t find an associated mount
point. For example, the device number for ‘/dev’ on our RHEL box at
work doesn’t match the device number of any of the mount points.

Which of these options seems most appropriate?

1 - Return nil
2 - Return ‘/’
3 - Return itself, e.g. ‘/dev’ would return ‘/dev’
4 - Raise an error

Suggestions?

Regards,

Dan

On Feb 23, 11:43 am, Daniel B. [email protected] wrote:

My dilemma is what I should do when I can’t find an associated mount
Suggestions?
Well, since no one chimed in, I went with “returns itself”.

BTW, I’ve released sys-filesystem 0.3.0, which now includes support
for FreeBSD and OS X. Thanks go to Nobuyoshi Miyokawa for that.

Regards,

Dan

Daniel B. wrote:

On Feb 23, 11:43�am, Daniel B. [email protected] wrote:

My dilemma is what I should do when I can’t find an associated mount
Suggestions?
Well, since no one chimed in, I went with “returns itself”.

First, sorry, haven’t got a clue what you are talking about. There is no
mounting point specified in your example!? But that is not the reason
for my reply. Rather, I would like to know where did the Filesystem
class came from, and if there is any documentation on this?

However, I do think, returning itself in this case is definitely not the
way to go, raising an error would be my preference!

Well, since no one chimed in, I went with “returns itself”.

Just a thought: a return value of nil would make it possible for
users
to opt for return-itself behaviour by using

Filesystem.mount_point(itself = '/home/djberge/foo.txt') || itself

I have no idea which case is be more likely but it seems to me that
returning itself gives users fewer choices. It seems to me that nil
would be more consistent with the usual ruby practice.


Leo

The end is here -->

Daniel B. wrote:

I don’t understand your question. It should be visible in the rdoc
generated when you did “gem install sys-filesystem”.

Thank you for your reply. The “gem install sys-filesystem” was not
obvious to me, instead I thought you may be talking about a new
expansion of standard Ruby classes, modules or interfaces.

On Feb 26, 2:58 pm, Igor P. [email protected] wrote:

Daniel B. wrote:

On Feb 23, 11:43 am, Daniel B. [email protected] wrote:

My dilemma is what I should do when I can’t find an associated mount
Suggestions?
Well, since no one chimed in, I went with “returns itself”.

First, sorry, haven’t got a clue what you are talking about. There is no
mounting point specified in your example!?

On our RHEL box, the device id for ‘/dev’ does not match the device id
of any of the mount points.

But that is not the reason
for my reply. Rather, I would like to know where did the Filesystem
class came from, and if there is any documentation on this?

I don’t understand your question. It should be visible in the rdoc
generated when you did “gem install sys-filesystem”.

Regards,

Dan