Problem with SYS_mount

[Eligiusz Narutowicz]

Re: Problem with SYS_mount

gazelle@xmissio n.xmission.com (Kenny McCormack) writes:

In article <fvora7$s6l$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>>Eric Sosman wrote:
>>
>>[drivel snipped]
>>

>> Here, as you've seen, you're likely to get drivel,
>>nonsense, and idiocy.
>>>

>>
>>You are the best example of that. Your post contains only that

>
Indeed. True of Sosman in general.
>
It was truly satisfying to see him finally come clean about his posting
style.

I am a little bit confused as why people are so keen for others not to
answer about things that they are knowing well about in C. Why is this?
I have seen about 5 posters who seems to be wanting not to help more
than they are helping. Very strange behaviours patterns.

[Nick Keighley]

Re: Problem with SYS_mount

On 6 May, 14:50, Eligiusz Narutowicz<elig iuszdotn...@hot mail.com>
wrote:

I am a little bit confused as why people are so keen for others not to
answer about things that they are knowing well about in C.

Because the questions are *not* about C. C is widely used
in a huge variety of situations and those applications
have nothing to do with C the programming language.

For instance C may be used to program anti-lock braking
systems but a discussion of the physics of ALBs though
possibly interesting is not on topic for this ng.

To avoid cluttering the group you should not post OT
stuff.

The reason many people think you should not reply
other than to point to a more relevant ng is that
few people in this group will be experts on the non-topic
stuff.

If someone asks a Linux question someone may give an answer.
It may be wrong. On a Linux group this will be quickly spotted
and corrected. So here is a good place to ask C questions.
It is not a good place to ask about SYS_mount.

Why is this?
I have seen about 5 posters who seems to be wanting not to help more
than they are helping. Very strange behaviours patterns

they are helping they are explaining to the poster where
he should have asked his question.


Do you seek financial or legal advice in a pub?
It's certainly available...



--
Nick Keighley

[Walter Roberson]

Re: Problem with SYS_mount

In article <fvpnnf$76i$1@r egistered.motza rella.org>,
Eligiusz Narutowicz <eligiuszdotnar u@hotmail.comwr ote:

>I am a little bit confused as why people are so keen for others not to
>answer about things that they are knowing well about in C. Why is this?
>I have seen about 5 posters who seems to be wanting not to help more
>than they are helping. Very strange behaviours patterns.

The things beings answered that you are referring to are *not* C,
they are third party libraries or system-specific functions
that happen to have a C interface. This newsgroup discusses
the C language as specified by one of the various iterations of the
standards -- discusses only that which is doable in un-extended C
and discusses the boundary conditions. It's a big enough topic just
by itself, and bringing in those third party libraries and system
specific functions and discussions of IDEs and what-not drowns out
the discussion of C itself, leading to the departure of the people
who are here to discuss C itself.

The third-party libraries and system functions have other newsgroups
or mailing lists or web sites where they can be discussed in detail
by experts in that functionality, and limitations or mistakes in
the answers noted by other experts. Those other experts are not *here*
so anything authoratative looking will not be cross-checked... and
yes, people *do* make mistakes. For example, in the recent sys_MOUNT
thread you were keen on, the answer you cited as "accurate" was *not*
accurate.

If operating-system specific or third-party libraries become topics
for this newsgroup, then the question arises "Where do you stop?"
Does this become a newsgroup for the discussion of *anything*
that has a C interface (even if the person is programming in, say,
8081 assembler)? They tried that in comp.lang.c++ and it pretty
much killed the newsgroup as a discussion place for C++ itself, I am told.

There a lot of other electronic fora around. This one is just for the
C language itself, not even for details of various implementations of C
(except perhaps the compile flags needed to get the implementation to
act as a conforming C implementation! ).
--
"I like to build things, I like to do things. I am having
a lot of fun." -- Walter Chrysler

[Ian Collins]

Re: Problem with SYS_mount

Eligiusz Narutowicz wrote:

Ian Collins <ian-news@hotmail.co mwrites:
>

>Richard Tobin wrote:

>>In article <1210023910.891 654@news1nwk>,
>>Eric Sosman <Eric.Sosman@su n.comwrote:
>>>
>>>>First of all, the prototype for the system call is
>>>>asmlinkag e long sys_mount(char __user *dev_name, char __user* dir_name,
>>>> char __user *type, unsigned long flags, void __user *data);
>>>>[...]
>>> Drivel. Nonsense. Idiocy.
>>I guess the OP's question concerns Linux, in which case it
>>would certainly make more sense to ask in a Linux group. But
>>as far as I can tell, Twink's response was fairly accurate.
>>>

>That the problem, isn't it? "as far as I can tell" isn't good enough,

>
Who cares if YOU can tell or not?
>
He got an accurate answer I can be sure to tell you. You do not know?
Then do not comment I think is best.

Congratulations on completely missing my point and snipping the line
that explained it.

--
Ian Collins.

[Antoninus Twink]

Re: Problem with SYS_mount

On 6 May 2008 at 14:19, Walter Roberson wrote:

... and yes, people *do* make mistakes. For example, in the recent
sys_MOUNT thread you were keen on, the answer you cited as "accurate"
was *not* accurate.

There was indeed an inaccuracy in my answer, and it would have been a
courtesy to the OP and others reading this discussion if you'd pointed
it out instead of getting on your high-horse.

Specifically, I said:

If you really want to work programatically , you can open one of the
loop devices, perform an ioctl on it (request LOOP_SET_FD with extra
argument "/home/sam/myfile.img"), then use mount(2).

This is wrong: the extra argument should be a file descriptor, not a
path name.

Here's a knock-up example of mounting a file programatically with a loop
device (of course it needs to be run with sufficient privileges to set up
the loop device and mount it).


#include <stdio.h>
#include <errno.h>

#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <sys/mount.h>
#include <linux/loop.h>

#define FILE_TO_MOUNT "/tmp/foo.iso"
#define MOUNT_PATH "/mnt"

int main(int argc, char **argv)
{
char dev[]="/dev/loop0";
int i, fd, fd2;
struct stat statbuf;
struct loop_info loopinfo;

/* find a free loop device */
for(i=0; i<8; i++) {
dev[9]='0'+i;
if( stat (dev, &statbuf) == 0 && S_ISBLK(statbuf .st_mode) )
if((fd = open (dev, O_RDONLY)) >= 0) {
if(ioctl(fd, LOOP_GET_STATUS , &loopinfo) && (errno == ENXIO))
break; /* got one! */
close(fd);
}
fd=-1;
}
if(fd==-1) {
fprintf(stderr, "%s: couldn't find free loop device\n", *argv);
return 1;
}

/* set up the loop device */
if((fd2=open(FI LE_TO_MOUNT, O_RDONLY)) < 0) {
fprintf(stderr, "%s: failed to open " FILE_TO_MOUNT "\n", *argv);
return 2;
}

if(ioctl(fd, LOOP_SET_FD, (void *) fd2)) {
fprintf(stderr, "%s: ioctl failed on %s\n", *argv, dev);
return 3;
}

/* do the mount */
if(mount(dev, MOUNT_PATH, "iso9660", MS_RDONLY, NULL)) {
fprintf(stderr, "%s: failed to mount %s on " MOUNT_PATH "\n", *argv, dev);
if (ioctl (fd, LOOP_CLR_FD, 0))
fprintf(stderr, "%s: failed to clear %s\n", *argv, dev);
return 4;
}

/* pause */
printf("Mounted " FILE_TO_MOUNT " at " MOUNT_PATH " using %s\n"
"Press enter to umount...\n", dev);
getchar();

/* do the umount */
if(umount(MOUNT _PATH)) {
fprintf(stderr, "%s: failed to umount %s on " MOUNT_PATH "\n", *argv, dev);
if (ioctl (fd, LOOP_CLR_FD, 0))
fprintf(stderr, "%s: failed to clear %s\n", *argv, dev);
return 5;
}

/* clean up */
close(fd2);
if (ioctl (fd, LOOP_CLR_FD, 0)) {
fprintf(stderr, "%s: failed to clear %s\n", *argv, dev);
return 6;
}
close(fd);

fprintf(stderr, "Umounted %s and cleared %s\n", MOUNT_PATH, dev);
return 0;
}

[CBFalconer]

Re: Problem with SYS_mount

Eligiusz Narutowicz wrote:

>

.... snip ...

>
I am a little bit confused as why people are so keen for others
not to answer about things that they are knowing well about in C.
Why is this? I have seen about 5 posters who seems to be wanting
not to help more than they are helping. Very strange behaviours
patterns.

It is simple. The topic here is C, as defined in the C standard.
While some users may be experts in other areas, there is no such
guarantee. Thus erroneous answers to non-topical questions may
never be corrected. This is easily avoided by simply placing the
question on a newsgroup where it actually is topical.

This doesn't mean that an off-topic answer is necessarily wrong, as
to fact. However it is wrong as to content, because it encourages
off-topic postings.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[Sam Joseph]

Re: Problem with SYS_mount

Brilliant, just what I was looking for! Thanks.

I don't understand the silly squabble that devlopped in this thread -
this is computer world, not an arts subject... there's no gray area,
either something's right (in which case what's the use in saying it's
wrong, when this can be easily checked), or it's wrong (in which case
just correct it).


Antoninus Twink wrote:

On 6 May 2008 at 14:19, Walter Roberson wrote:
>

>>... and yes, people *do* make mistakes. For example, in the recent
>>sys_MOUNT thread you were keen on, the answer you cited as "accurate"
>>was *not* accurate.

>
>
There was indeed an inaccuracy in my answer, and it would have been a
courtesy to the OP and others reading this discussion if you'd pointed
it out instead of getting on your high-horse.
>
Specifically, I said:
>

>>If you really want to work programatically , you can open one of the
>>loop devices, perform an ioctl on it (request LOOP_SET_FD with extra
>>argument "/home/sam/myfile.img"), then use mount(2).

>
>
This is wrong: the extra argument should be a file descriptor, not a
path name.
>
Here's a knock-up example of mounting a file programatically with a loop
device (of course it needs to be run with sufficient privileges to set up
the loop device and mount it).
>
>
#include <stdio.h>
#include <errno.h>
>
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <sys/mount.h>
#include <linux/loop.h>
>
#define FILE_TO_MOUNT "/tmp/foo.iso"
#define MOUNT_PATH "/mnt"
>
int main(int argc, char **argv)
{
char dev[]="/dev/loop0";
int i, fd, fd2;
struct stat statbuf;
struct loop_info loopinfo;
>
/* find a free loop device */
for(i=0; i<8; i++) {
dev[9]='0'+i;
if( stat (dev, &statbuf) == 0 && S_ISBLK(statbuf .st_mode) )
if((fd = open (dev, O_RDONLY)) >= 0) {
if(ioctl(fd, LOOP_GET_STATUS , &loopinfo) && (errno == ENXIO))
break; /* got one! */
close(fd);
}
fd=-1;
}
if(fd==-1) {
fprintf(stderr, "%s: couldn't find free loop device\n", *argv);
return 1;
}
>
/* set up the loop device */
if((fd2=open(FI LE_TO_MOUNT, O_RDONLY)) < 0) {
fprintf(stderr, "%s: failed to open " FILE_TO_MOUNT "\n", *argv);
return 2;
}
>
if(ioctl(fd, LOOP_SET_FD, (void *) fd2)) {
fprintf(stderr, "%s: ioctl failed on %s\n", *argv, dev);
return 3;
}
>
/* do the mount */
if(mount(dev, MOUNT_PATH, "iso9660", MS_RDONLY, NULL)) {
fprintf(stderr, "%s: failed to mount %s on " MOUNT_PATH "\n", *argv, dev);
if (ioctl (fd, LOOP_CLR_FD, 0))
fprintf(stderr, "%s: failed to clear %s\n", *argv, dev);
return 4;
}
>
/* pause */
printf("Mounted " FILE_TO_MOUNT " at " MOUNT_PATH " using %s\n"
"Press enter to umount...\n", dev);
getchar();
>
/* do the umount */
if(umount(MOUNT _PATH)) {
fprintf(stderr, "%s: failed to umount %s on " MOUNT_PATH "\n", *argv, dev);
if (ioctl (fd, LOOP_CLR_FD, 0))
fprintf(stderr, "%s: failed to clear %s\n", *argv, dev);
return 5;
}
>
/* clean up */
close(fd2);
if (ioctl (fd, LOOP_CLR_FD, 0)) {
fprintf(stderr, "%s: failed to clear %s\n", *argv, dev);
return 6;
}
close(fd);
>
fprintf(stderr, "Umounted %s and cleared %s\n", MOUNT_PATH, dev);
return 0;
}
>

[Kenny McCormack]

Re: Problem with SYS_mount

In article <fvrkpv$mim$1@a ioe.org>, Sam Joseph <spamtrap@nospa m.comwrote:

>Brilliant, just what I was looking for! Thanks.
>
>I don't understand the silly squabble that devlopped in this thread -
>this is computer world, not an arts subject... there's no gray area,
>either something's right (in which case what's the use in saying it's
>wrong, when this can be easily checked), or it's wrong (in which case
>just correct it).

Welcome to CLC!

Bottom line here is: Despite the name, this newsgroup (comp.lang.c) is
not about computers or technology. So, a lot of your basic assumptions
about, as you put it "computer world", do not apply here.

Rather, this is a newsgroup devoted to a particular species of theology.
It is only in the realm of theology that you see people with a deep,
vested interest in believing things that simply aren't so (with a tip of
the hat to Mark Twain). Hence, the endless arguments between the
Establishment (intent on perpetuating the belief in and acceptance of
the theology) and the skeptics (those in the so-called "reality-based
community"). Since there is no resolution to this problem (neither side
is willing to concede any territory), the debate will go on forever.

[Eligiusz Narutowicz]

Re: Problem with SYS_mount

Ian Collins <ian-news@hotmail.co mwrites:

Eligiusz Narutowicz wrote:

>Ian Collins <ian-news@hotmail.co mwrites:
>>

>>Richard Tobin wrote:
>>>In article <1210023910.891 654@news1nwk>,
>>>Eric Sosman <Eric.Sosman@su n.comwrote:
>>>>
>>>>>First of all, the prototype for the system call is
>>>>>asmlinka ge long sys_mount(char __user *dev_name, char __user* dir_name,
>>>>> char __user *type, unsigned long flags, void __user *data);
>>>>>[...]
>>>> Drivel. Nonsense. Idiocy.
>>>I guess the OP's question concerns Linux, in which case it
>>>would certainly make more sense to ask in a Linux group. But
>>>as far as I can tell, Twink's response was fairly accurate.
>>>>
>>That the problem, isn't it? "as far as I can tell" isn't good enough,

>>
>Who cares if YOU can tell or not?
>>
>He got an accurate answer I can be sure to tell you. You do not know?
>Then do not comment I think is best.

>
Congratulations on completely missing my point and snipping the line
that explained it.

No. I did not miss your point. It seems you just to be stopping people
answering because you do not understand. This is a C newsgroup. The OP
has an answer. Something to work with.

[CBFalconer]

Re: Problem with SYS_mount

Eligiusz Narutowicz wrote:

Ian Collins <ian-news@hotmail.co mwrites:
>

.... snip ...

>

>Congratulation s on completely missing my point and snipping the
>line that explained it.

>
No. I did not miss your point. It seems you just to be stopping
people answering because you do not understand. This is a C
newsgroup. The OP has an answer. Something to work with.

Yes you did. The C language is defined by the C standard, present
and past. Material to do with other things is not topical, unless
the routines to provide those services are also written in purely
standard C and published IN THE MESSAGE. This is a fairly critical
standard, but avoids having the newsgroup go off in all directions,
and system specific newsgroups are generally available for
non-C-topical queries.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[CBFalconer]

Re: Problem with SYS_mount

Sam Joseph wrote:

>
Brilliant, just what I was looking for! Thanks.
>
I don't understand the silly squabble that devlopped in this thread
- this is computer world, not an arts subject... there's no gray
area, either something's right (in which case what's the use in
saying it's wrong, when this can be easily checked), or it's wrong
(in which case just correct it).

The point is that the group deals with standard C as defined in the
various C standards. Other material is off-topic, and there is no
reason to assume any readers here will (or can) correct it if
erroneous.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html >
<http://www.netmeister. org/news/learn2quote.htm l>
<http://cfaj.freeshell. org/google/ (taming google)
<http://members.fortune city.com/nnqweb/ (newusers)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[Walter Roberson]

Re: Problem with SYS_mount

In article <fvrkpv$mim$1@a ioe.org>, Sam Joseph <spamtrap@nospa m.comwrote:

>I don't understand the silly squabble that devlopped in this thread -
>this is computer world, not an arts subject... there's no gray area,
>either something's right (in which case what's the use in saying it's
>wrong, when this can be easily checked), or it's wrong (in which case
>just correct it).

The material provided by Mr. Twink in his or her first reply was
*completely* incorrect on at least 3 systems I have personally had
access to, and my research the other day found that it was incorrect
for at least one of the major branches of Unix. Your
"just correct it" idea would require scowering over several hundreds
of implementations and providing the corrected answer for each of them.

System-specific answers should simply not be provided here, especially
without firm statements of which systems they are specific to.
--
"I want to be remembered as the guy who gave his all whenever
he was on the field." -- Walter Payton

[Eric Sosman]

Re: Problem with SYS_mount

Sam Joseph wrote:

Brilliant, just what I was looking for! Thanks.
>
I don't understand the silly squabble that devlopped in this thread -
this is computer world, not an arts subject... there's no gray area,
either something's right (in which case what's the use in saying it's
wrong, when this can be easily checked), or it's wrong (in which case
just correct it).

The computer world is a wide one, so to make knowledge
manageable and accessible there must be some amount of
classification and compartmentaliz ation. A useful library
does not just throw all the books onto the shelves helter-
skelter, but groups related volumes together: cooking
here, woodworking there, history through that door on your
left, and so on.

You have found yourself among the shelves that are in
theory devoted to the programming language C, but your
question was not about C. True, it was about a program
fragment expressed in C, but the question was not about C.
(A simple way to see that this is so is to note that from
the point of view of the C language there was nothing at
all wrong with the fragment you posted; whatever problem
you were having was therefore not a C problem but something
else.) You have, as it were, searched the English Grammar
shelves for help assembling your gas grill: the instructions
are in English, but your troubles in executing them have to
do with the leaky fittings and not with English.

Finally, the notion that "there's no gray area, either
something's right [...] or it's wrong" is one you will grow
out of as you gain some experience. Context has more
importance than you give it credit for.

--
Eric.Sosman@sun .com

[Kenny McCormack]

Re: Problem with SYS_mount

In article <fvsn2e$2fv$1@c anopus.cc.umani toba.ca>,
Walter Roberson <roberson@ibd.n rc-cnrc.gc.cawrote :

>In article <fvrkpv$mim$1@a ioe.org>, Sam Joseph <spamtrap@nospa m.comwrote:
>

>>I don't understand the silly squabble that devlopped in this thread -
>>this is computer world, not an arts subject... there's no gray area,
>>either something's right (in which case what's the use in saying it's
>>wrong, when this can be easily checked), or it's wrong (in which case
>>just correct it).

>
>The material provided by Mr. Twink in his or her first reply was
>*completely* incorrect on at least 3 systems I have personally had

Yeah, I couldn't get it to work on my Nintendo box, either.