cp: strange message !?

Hi,
I want to copy some files like that:
cp -R /net/proto_qrtp_1/VA01109-1/* /

In /VA01109-1 there is a ds directory with some .dat files (ascii files).
For all these files I get:
cp: skipping file …
cp: (File resides on different device).

Now if I write the command like that:
cp -R /net/proto_qrtp_1/VA01109-1/ds/* /VA01109-1/ds

That works!

All directories and files are regular and not links.

What’s the problem?

Thanks,
Alain.

cp shouldn’t do that unless that -N option was specified. The -N option
affects recursive copying (-R), telling cp to skip input files that lie
under, but reside on a different device from, their parent directories
specified on the command line. ‘whence cp’ from the command line or ‘sin
args’ while cp is running should show you the actual arguments that are
being passed to the utility. ‘sin args’ will also be useful if you have any
doubts at all about what those filename expansions (directory/*) are turning
into before they are passed as command line arguments to the utility.
The -D option will override the behavior; just make sure the -D follows
the -N on the command line.

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3E2BEEC0.7000406@icbt.com

Hi,
I want to copy some files like that:
cp -R /net/proto_qrtp_1/VA01109-1/* /

In /VA01109-1 there is a ds directory with some .dat files (ascii files).
For all these files I get:
cp: skipping file …
cp: (File resides on different device).

Now if I write the command like that:
cp -R /net/proto_qrtp_1/VA01109-1/ds/* /VA01109-1/ds

That works!

All directories and files are regular and not links.

What’s the problem?

Thanks,
Alain.

Ok Eric, that works with -D flag but I don’t understand what happens
exactly. The meanning of -D doesn’t correspond to my case and today,
without -D the problem occurs on different files. So, I think there is a
problem somewhere in the filesystem (checked ok anyway) or in cp in 6.1.
On another machine, under root, I want to copy a file ‘cp ./tmp/dio
/usr/bin/’ and I get 'cp: can’t open destination file. (/usr/bin///dio).
No such file or directory.

What cp has against me?!?

regards,
Alain.

Eric Johnson a écrit:

cp shouldn’t do that unless that -N option was specified. The -N option
affects recursive copying (-R), telling cp to skip input files that lie
under, but reside on a different device from, their parent directories
specified on the command line. ‘whence cp’ from the command line or ‘sin
args’ while cp is running should show you the actual arguments that are
being passed to the utility. ‘sin args’ will also be useful if you have any
doubts at all about what those filename expansions (directory/*) are turning
into before they are passed as command line arguments to the utility.
The -D option will override the behavior; just make sure the -D follows
the -N on the command line.

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3E2BEEC0.7000406@icbt.com> …


Hi,
I want to copy some files like that:
cp -R /net/proto_qrtp_1/VA01109-1/* /

In /VA01109-1 there is a ds directory with some .dat files (ascii files).
For all these files I get:
cp: skipping file …
cp: (File resides on different device).

Now if I write the command like that:
cp -R /net/proto_qrtp_1/VA01109-1/ds/* /VA01109-1/ds

That works!

All directories and files are regular and not links.

What’s the problem?

Thanks,
Alain.



\

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3E34E1D0.50405@icbt.com

Ok Eric, that works with -D flag but I don’t understand what happens
exactly. The meanning of
-D doesn’t correspond to my case and today, without -D the problem occurs
on different files.
So, I think there is a problem somewhere in the filesystem (checked ok
anyway) or in cp in 6.1.

What did ‘whence cp’ and ‘sin args’ (whilst cp was running) tell you? -D
shouldn’t have any effect at all unless -N was also specified. We generally
don’t use -N on a QNX Neutrino desktop system because the package filesystem
will introduce new devices for various files/dirs within the virtual
pathname space it creates. I did some testing of this on my own desktop, and
yes there are lots of files that cp skips, but both a diagnostic version of
cp that prints out the st_dev values involved, and a separate utility that
dumps stat information, confirmed that it was doing the right thing (at
least in my test case). That’s not to say it can’t have a bug; maybe it
does, but it’s equally probably that you’re seeing a side-effect of
something else (like the package filesystem). You might want to make a quick
little program that takes a filename as a command line argument, does an
lstat, and prints it’s st_dev number. This would let you see directly
whether or not the files/dirs have the same device number, and if cp does
have a bug, it will help us pinpoint it.

On another machine, under root, I want to copy a file ‘cp ./tmp/dio
/usr/bin/’ and I get 'cp: can’t open >destination file. (/usr/bin///dio). No

such file or directory.

I suspect this is unrelated to the first problem. Don’t be fooled by the
extra slashes – multiple slashes are the equivalent of a single slash. Did
/usr/bin already exist? What were the permissions on the relevant files?

What cp has against me?!?

Hopefully nothing, but you never know. :slight_smile:

Hi Eric,
I didn’t find ‘whence’ and I don’t see how to ‘sin args’ cp unless on a
10 Mo file!
I can understand that cp skip ‘virtual’ files belonging to fs-pkgs but
it seems there is a problem somewhere.
I tried to copy /etc/rc.d/rc.local in two ways:

cp -Rcv /net/estape_qrtp_2/etc/ /fs/hd1-qnx4/etc
I get Skipping files … for ALL files beginning by country.

Now if I cp the files individually:

cp -Rcv /net/estape_qrtp_2/etc/country /fs/hd1-qnx4/etc

that works perfectly, and for ALL files

cp -WRcv displays:

cp: LSTAT(/fs/hd1-qnx4/,buf)
cp: LSTAT(/net/estape_qrtp_2/etc,buf)
cp: LSTAT(/fs/hd1-qnx4/etc,buf)
cp: OPENDIR(/net/estape_qrtp_2/etc)
cp: LSTAT(/net/estape_qrtp_2/etc/country,buf)
cp: Skipping file /net/estape_qrtp_2/etc/country
cp: (File resides on different device
cp: ERRS++ (1) src file not on source device
etc…, etc…,etc…

I modified the lstat() example from your doc to add the st_dev printf,
that give:
/net/estape_qrtp_2/etc/ is not a symbolic link
/net/estape_qrtp_2/etc/ st_dev: 2055
/net/estape_qrtp_2/etc/country is not a symbolic link
/net/estape_qrtp_2/etc/country st_dev: 2053

Does it enlighten you?

cheers,
Alain.
Eric Johnson a écrit:

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3E34E1D0.50405@icbt.com> …


Ok Eric, that works with -D flag but I don’t understand what happens


exactly. The meanning of


-D doesn’t correspond to my case and today, without -D the problem occurs


on different files.


So, I think there is a problem somewhere in the filesystem (checked ok


anyway) or in cp in 6.1.

What did ‘whence cp’ and ‘sin args’ (whilst cp was running) tell you? -D
shouldn’t have any effect at all unless -N was also specified. We generally
don’t use -N on a QNX Neutrino desktop system because the package filesystem
will introduce new devices for various files/dirs within the virtual
pathname space it creates. I did some testing of this on my own desktop, and
yes there are lots of files that cp skips, but both a diagnostic version of
cp that prints out the st_dev values involved, and a separate utility that
dumps stat information, confirmed that it was doing the right thing (at
least in my test case). That’s not to say it can’t have a bug; maybe it
does, but it’s equally probably that you’re seeing a side-effect of
something else (like the package filesystem). You might want to make a quick
little program that takes a filename as a command line argument, does an
lstat, and prints it’s st_dev number. This would let you see directly
whether or not the files/dirs have the same device number, and if cp does
have a bug, it will help us pinpoint it.



On another machine, under root, I want to copy a file ‘cp ./tmp/dio


/usr/bin/’ and I get 'cp: can’t open >destination file. (/usr/bin///dio). No
such file or directory.

I suspect this is unrelated to the first problem. Don’t be fooled by the
extra slashes – multiple slashes are the equivalent of a single slash. Did
/usr/bin already exist? What were the permissions on the relevant files?



What cp has against me?!?



Hopefully nothing, but you never know. > :slight_smile:

\

You said that -D hasn’t any effect alone, but the following command
works perfectly:

cp -DWRc /net/estape_qrtp_2/etc fs/hd1-qnx4/

cp: LSTAT(/fs/hd1-qnx4/,buf)
cp: LSTAT(/net/estape_qrtp_2/etc,buf)
cp: LSTAT(/fs/hd1-qnx4/etc,buf)
cp: OPENDIR(/net/estape_qrtp_2/etc)
cp: LSTAT(/net/estape_qrtp_2/etc/country,buf)
cp: copy_guy(/net/estape_qrtp_2/etc/country,/fs/hd1-qnx4/etc/country)
cp: OPEN(/net/estape_qrtp_2/etc/country,0,0)
cp: OPEN(/fs/hd1-qnx4/etc/country,2401,100664)
cp: LSTAT(/fs/hd1-qnx4/etc/country,buf)
cp: Copying /net/estape_qrtp_2/etc/country to /fs/hd1-qnx4/etc/country
cp: past_data_copy errs_in =0, errs = 0
cp: __FUTIME(out,&utm) utm.atime=993776846, utm.mtime=987615406
cp: FCHMOD(6,100664)
cp: exit_copy_guy (rc=0)
cp: CLOSE(fildes)
cp: CLOSE(fildes)

cheers,
Alain.

Alain Bonnefoy a écrit:

Hi Eric,
I didn’t find ‘whence’ and I don’t see how to ‘sin args’ cp unless on
a 10 Mo file!
I can understand that cp skip ‘virtual’ files belonging to fs-pkgs but
it seems there is a problem somewhere.
I tried to copy /etc/rc.d/rc.local in two ways:

cp -Rcv /net/estape_qrtp_2/etc/ /fs/hd1-qnx4/etc
I get Skipping files … for ALL files beginning by country.

Now if I cp the files individually:

cp -Rcv /net/estape_qrtp_2/etc/country /fs/hd1-qnx4/etc

that works perfectly, and for ALL files

cp -WRcv displays:

cp: LSTAT(/fs/hd1-qnx4/,buf)
cp: LSTAT(/net/estape_qrtp_2/etc,buf)
cp: LSTAT(/fs/hd1-qnx4/etc,buf)
cp: OPENDIR(/net/estape_qrtp_2/etc)
cp: LSTAT(/net/estape_qrtp_2/etc/country,buf)
cp: Skipping file /net/estape_qrtp_2/etc/country
cp: (File resides on different device
cp: ERRS++ (1) src file not on source device
etc…, etc…,etc…

I modified the lstat() example from your doc to add the st_dev printf,
that give:
/net/estape_qrtp_2/etc/ is not a symbolic link
/net/estape_qrtp_2/etc/ st_dev: 2055
/net/estape_qrtp_2/etc/country is not a symbolic link
/net/estape_qrtp_2/etc/country st_dev: 2053

Does it enlighten you?

cheers,
Alain.
Eric Johnson a écrit:

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3E34E1D0.50405@icbt.com> …


Ok Eric, that works with -D flag but I don’t understand what happens


exactly. The meanning of


-D doesn’t correspond to my case and today, without -D the problem occurs


on different files.


So, I think there is a problem somewhere in the filesystem (checked ok


anyway) or in cp in 6.1.

What did ‘whence cp’ and ‘sin args’ (whilst cp was running) tell you? -D
shouldn’t have any effect at all unless -N was also specified. We generally
don’t use -N on a QNX Neutrino desktop system because the package filesystem
will introduce new devices for various files/dirs within the virtual
pathname space it creates. I did some testing of this on my own desktop, and
yes there are lots of files that cp skips, but both a diagnostic version of
cp that prints out the st_dev values involved, and a separate utility that
dumps stat information, confirmed that it was doing the right thing (at
least in my test case). That’s not to say it can’t have a bug; maybe it
does, but it’s equally probably that you’re seeing a side-effect of
something else (like the package filesystem). You might want to make a quick
little program that takes a filename as a command line argument, does an
lstat, and prints it’s st_dev number. This would let you see directly
whether or not the files/dirs have the same device number, and if cp does
have a bug, it will help us pinpoint it.



On another machine, under root, I want to copy a file ‘cp ./tmp/dio


/usr/bin/’ and I get 'cp: can’t open >destination file. (/usr/bin///dio). No
such file or directory.

I suspect this is unrelated to the first problem. Don’t be fooled by the
extra slashes – multiple slashes are the equivalent of a single slash. Did
/usr/bin already exist? What were the permissions on the relevant files?



What cp has against me?!?



Hopefully nothing, but you never know. > :slight_smile:


\

Alain,

From the information you provided, it seems that other than -N apparently being in effect for some reason, cp appears to be doing the right thing.

Your lstat example program showed that /net/estape_qrtp_2/etc (the directory) is on a different device from /net/estape_qrtp_2/etc/country. With -N in effect, cp should therefore skip /etc/country when recursively copying /etc. It looks like you have a typical Neutrino desktop configuration, and as I guessed it is the package filesystem that is doing this.

Now, the question remains as to why it is doing this at all, since you are not specifying -N at the command line.
The ‘whence’ utility is a builtin command in ksh (documented under ksh in the Utilities Reference). From the shell, just type ‘whence cp’ and it will tell you what will run when you type ‘cp’ (either telling you which binary it will run, or the alias it will replace your command with). If you have inadvertently aliased cp, you could also get this info by typing ‘alias cp’, or just ‘alias’ to get a list of all your command aliases. I thought that since you were doing a recursive copy, it might take long enough for ‘sin args’ to snag its command line as it runs.

‘sin args’ is more definitive since it will also show the result of any wildcard expansions done on the command line. Both of these are trying to get at the same information: the exact command line options being passed to cp.
Though its unlikely to be the root cause of the problem you’re seeing, wildcard expansions can do surprising things. For example:

mkdir testdir
touch testdir/-W
touch testdir/file
cd testdir
cp * /dev/null

[Note that -W is in effect even though you did not specify it on the command line. This is because the shell passed it to cp as the first command line parameter when it expanded *. You can prevent accidental misinterpretation of arguments as options by preceding the arguments with a ‘–’, e.g. cp – * /dev/null. ]

  • Eric

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message news:3E3694AB.6000403@icbt.com
Hi Eric,
I didn’t find ‘whence’ and I don’t see how to ‘sin args’ cp unless on a 10 Mo file!
I can understand that cp skip ‘virtual’ files belonging to fs-pkgs but it seems there is a problem somewhere.
I tried to copy /etc/rc.d/rc.local in two ways:

cp -Rcv /net/estape_qrtp_2/etc/ /fs/hd1-qnx4/etc
I get Skipping files … for ALL files beginning by country.

Now if I cp the files individually:

cp -Rcv /net/estape_qrtp_2/etc/country /fs/hd1-qnx4/etc

that works perfectly, and for ALL files

cp -WRcv displays:

cp: LSTAT(/fs/hd1-qnx4/,buf)
cp: LSTAT(/net/estape_qrtp_2/etc,buf)
cp: LSTAT(/fs/hd1-qnx4/etc,buf)
cp: OPENDIR(/net/estape_qrtp_2/etc)
cp: LSTAT(/net/estape_qrtp_2/etc/country,buf)
cp: Skipping file /net/estape_qrtp_2/etc/country
cp: (File resides on different device
cp: ERRS++ (1) src file not on source device
etc…, etc…,etc…

I modified the lstat() example from your doc to add the st_dev printf, that give:
/net/estape_qrtp_2/etc/ is not a symbolic link
/net/estape_qrtp_2/etc/ st_dev: 2055
/net/estape_qrtp_2/etc/country is not a symbolic link
/net/estape_qrtp_2/etc/country st_dev: 2053

Does it enlighten you?

cheers,
Alain.
Eric Johnson a écrit:

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3E34E1D0.50405@icbt.com

Ok Eric, that works with -D flag but I don’t understand what happens

exactly. The meanning of

-D doesn’t correspond to my case and today, without -D the problem occurs

on different files.

So, I think there is a problem somewhere in the filesystem (checked ok

anyway) or in cp in 6.1.

What did ‘whence cp’ and ‘sin args’ (whilst cp was running) tell you? -D
shouldn’t have any effect at all unless -N was also specified. We generally
don’t use -N on a QNX Neutrino desktop system because the package filesystem
will introduce new devices for various files/dirs within the virtual
pathname space it creates. I did some testing of this on my own desktop, and
yes there are lots of files that cp skips, but both a diagnostic version of
cp that prints out the st_dev values involved, and a separate utility that
dumps stat information, confirmed that it was doing the right thing (at
least in my test case). That’s not to say it can’t have a bug; maybe it
does, but it’s equally probably that you’re seeing a side-effect of
something else (like the package filesystem). You might want to make a quick
little program that takes a filename as a command line argument, does an
lstat, and prints it’s st_dev number. This would let you see directly
whether or not the files/dirs have the same device number, and if cp does
have a bug, it will help us pinpoint it.


On another machine, under root, I want to copy a file 'cp ./tmp/dio

/usr/bin/’ and I get 'cp: can’t open >destination file. (/usr/bin///dio). No
such file or directory.

I suspect this is unrelated to the first problem. Don’t be fooled by the
extra slashes – multiple slashes are the equivalent of a single slash. Did
/usr/bin already exist? What were the permissions on the relevant files?


What cp has against me?!?


Hopefully nothing, but you never know. :slight_smile:

Eric Johnson a écrit:

Alain,

From the information you provided, it seems that other than -N
apparently being in effect for some reason, cp appears to be doing the
right thing.

I think you make a mistake about -N flag or it’s an undocumented
feature. At least in 6.1.

Your lstat example program showed that /net/estape_qrtp_2/etc (the
directory) is on a different device from
/net/estape_qrtp_2/etc/country. With -N in effect, cp should therefore
skip /etc/country when recursively copying /etc. It looks like
you have a typical Neutrino desktop configuration, and as I guessed it
is the package filesystem that is doing this.

Sure.

Now, the question remains as to why it is doing this at all, since you
are not specifying -N at the command line.
The ‘whence’ utility is a builtin command in ksh (documented under
ksh in the Utilities Reference). From the shell, just type ‘whence cp’
and it will tell you what will run when you type ‘cp’ (either telling
you which binary it will run, or the alias it will replace your
command with).

ok ‘whence cp’ gives /bin/cp

If you have inadvertently aliased cp, you could also get this info by
typing ‘alias cp’, or just ‘alias’ to get a list of all your command
aliases.

I haven’t any aliases about cp.

I thought that since you were doing a recursive copy, it might take
long enough for ‘sin args’ to snag its command line as it runs.

‘sin args’ is more definitive since it will also show the result of
any wildcard expansions done on the command line. Both of these are
trying to get at the same information: the exact command line
options being passed to cp.
Though its unlikely to be the root cause of the problem you’re seeing,
wildcard expansions can do surprising things. For example:

mkdir testdir
touch testdir/-W
touch testdir/file
cd testdir
cp * /dev/null

[Note that -W is in effect even though you did not specify it on the
command line. This is because the shell passed it to cp as the first
command line parameter when it expanded *. You can prevent accidental
misinterpretation of arguments as options by preceding the arguments
with a ‘–’, e.g. cp – * /dev/null. ]

  • Eric

Hum, well, I tried to trap cp with sin args but I definitively haven’t
any chance to get the pertinent information.

But the reason seems to be quite clear. In fact I saw that /etc is a
real directory even when country belongs to fs-pkg. So, cp don’t want to
copy it as it consider it resides on a different device. Meanning, it
doesn’t exist on the hard disk.

->May be it could be usefull to distinguish fs-pkg from virtual devices.
I mean I make a difference between /etc/country and /dev/ser1 for example.
Today it’s impossible to copy /etc/country from a recursive cp. Or I’m
going to copy /dev, /dev/mem, /proc,… if I use -D flag. Even though it
could be necessary to be able to copy /dev/shmem for example.
So, it could be usefull to have a flag to consider fs-pkg as a part of
the hd filesytem, and -D for the actual meanning.
What’s your opinion?

cheers,
Alain.

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com
mailto:> alain.bonnefoy@icbt.com> >> wrote in message
news:> 3E3694AB.6000403@icbt.com> …
Hi Eric,
I didn’t find ‘whence’ and I don’t see how to ‘sin args’ cp unless
on a 10 Mo file!
I can understand that cp skip ‘virtual’ files belonging to fs-pkgs
but it seems there is a problem somewhere.
I tried to copy /etc/rc.d/rc.local in two ways:

cp -Rcv /net/estape_qrtp_2/etc/ /fs/hd1-qnx4/etc
I get Skipping files … for ALL files beginning by country.

Now if I cp the files individually:

cp -Rcv /net/estape_qrtp_2/etc/country /fs/hd1-qnx4/etc

that works perfectly, and for ALL files

cp -WRcv displays:

cp: LSTAT(/fs/hd1-qnx4/,buf)
cp: LSTAT(/net/estape_qrtp_2/etc,buf)
cp: LSTAT(/fs/hd1-qnx4/etc,buf)
cp: OPENDIR(/net/estape_qrtp_2/etc)
cp: LSTAT(/net/estape_qrtp_2/etc/country,buf)
cp: Skipping file /net/estape_qrtp_2/etc/country
cp: (File resides on different device
cp: ERRS++ (1) src file not on source device
etc…, etc…,etc…

I modified the lstat() example from your doc to add the st_dev
printf, that give:
/net/estape_qrtp_2/etc/ is not a symbolic link
/net/estape_qrtp_2/etc/ st_dev: 2055
/net/estape_qrtp_2/etc/country is not a symbolic link
/net/estape_qrtp_2/etc/country st_dev: 2053

Does it enlighten you?

cheers,
Alain.
Eric Johnson a écrit:

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3E34E1D0.50405@icbt.com> …


Ok Eric, that works with -D flag but I don’t understand what happens


exactly. The meanning of


-D doesn’t correspond to my case and today, without -D the problem occurs


on different files.


So, I think there is a problem somewhere in the filesystem (checked ok


anyway) or in cp in 6.1.

What did ‘whence cp’ and ‘sin args’ (whilst cp was running) tell you? -D
shouldn’t have any effect at all unless -N was also specified. We generally
don’t use -N on a QNX Neutrino desktop system because the package filesystem
will introduce new devices for various files/dirs within the virtual
pathname space it creates. I did some testing of this on my own desktop, and
yes there are lots of files that cp skips, but both a diagnostic version of
cp that prints out the st_dev values involved, and a separate utility that
dumps stat information, confirmed that it was doing the right thing (at
least in my test case). That’s not to say it can’t have a bug; maybe it
does, but it’s equally probably that you’re seeing a side-effect of
something else (like the package filesystem). You might want to make a quick
little program that takes a filename as a command line argument, does an
lstat, and prints it’s st_dev number. This would let you see directly
whether or not the files/dirs have the same device number, and if cp does
have a bug, it will help us pinpoint it.



On another machine, under root, I want to copy a file ‘cp ./tmp/dio


/usr/bin/’ and I get 'cp: can’t open >destination file. (/usr/bin///dio). No
such file or directory.

I suspect this is unrelated to the first problem. Don’t be fooled by the
extra slashes – multiple slashes are the equivalent of a single slash. Did
/usr/bin already exist? What were the permissions on the relevant files?



What cp has against me?!?



Hopefully nothing, but you never know. > :slight_smile:


\

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3E379E6C.3070605@icbt.com> …
I think you make a mistake about -N flag or it’s an undocumented feature.
At least in 6.1.

Alain, you’re absolutely right; I wasn’t paying close enough attention to
the version of Neutrino you’re using.

The default under 6.1 is to not descend past device boundaries on recursive
copies, which explains what you’re seeing. -N was introduced in 6.2 when the
default behavior was changed to ignore device boundaries.

Here are some options available to you at this point:

  1. Use -D. The -D option will work in either case (either allowing descent
    under 6.1 or reiterating the default under 6.2 and later).

  2. Set the POSIX_STRICT environment variable. This will disable the QNX
    extensions to cp and will also change the behavior in other ways, one of
    which is to ignore device boundaries on recursive copies (but if you do this
    you’ll also have to live with the side-effects).

  3. Use 6.2.


    Sorry again for not paying proper attention to the version you were using. I
    guess I get to take away a lesson from this discussion too. :slight_smile:

Hi Eric,

Eric Johnson a écrit:

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message


news:> 3E379E6C.3070605@icbt.com> …


I think you make a mistake about -N flag or it’s an undocumented feature.


At least in 6.1.

Alain, you’re absolutely right; I wasn’t paying close enough attention to
the version of Neutrino you’re using.

The default under 6.1 is to not descend past device boundaries on recursive
copies, which explains what you’re seeing. -N was introduced in 6.2 when the
default behavior was changed to ignore device boundaries.

Here are some options available to you at this point:

  1. Use -D. The -D option will work in either case (either allowing descent
    under 6.1 or reiterating the default under 6.2 and later).

  2. Set the POSIX_STRICT environment variable. This will disable the QNX
    extensions to cp and will also change the behavior in other ways, one of
    which is to ignore device boundaries on recursive copies (but if you do this
    you’ll also have to live with the side-effects).

  3. Use 6.2.


    It’s planned!

But you don’t really answer to one question:
Do you now make difference between a virtual device like /dev/mem and a
regular file belonging to fs-pkg like /etc/country in ‘cp -R’ behaviour?

Sorry again for not paying proper attention to the version you were using. I
guess I get to take away a lesson from this discussion too. > :slight_smile:




It’s a good thing > :wink:

Thanks,
Alain

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3E391F13.8050402@icbt.com


But you don’t really answer to one question:
Do you now make difference between a virtual device like /dev/mem and a
regular file belonging to fs-pkg like /etc/country in ‘cp -R’ behaviour?

I don’t understand your question, so I’ll just explain a bit more and if
this doesn’t cover what you need to know, perhaps you can rephrase.

With cp -R (in -N mode; i.e. either the default 6.1 behavior or -N with
6.2), cp will ignore (i.e. not copy to the destination) any source files
that reside on a different device from the directory you specify to cp on
the command line. This “different device” could be real or virtual – all
that matters as far as cp is concerned is that the st_dev field differs
between the source file and its parent directory.

Depending on what you are trying to do, this is can be a problem when the
package filesystem is running.

Not only does the package filesystem present lots of files and directories
on virtual devices, but because of pathname unioning, many directories will
exist both physically on the disk as part of the real filesystem and
virtually as part of a package.

/etc is present both virtually as part of multiple packages, and on disk as
part of your physical filesystem

On a typical system /etc resides both on the physical disk (e.g. to contain
/etc/shadow, which is not present in a package) and as part of more than one
package administered by fs-pkg. When you readdir() or ls the directory, or
try to access a file within it, the pathname spaces are merged such that you
seamlessly see and access the combined contents of all the virtual and real
filesystems that ‘own’ /etc or files/dirs within it. When you stat() the
/etc directory itself, you’ll get the information pertaining to just one of
the multiple /etc directories that may overlap in that part of the pathname
space. Which one will you get? Well, typically on a normal Neutrino
development desktop you’d get one of the package filesystem versions, but if
more programs adopted that part of the pathname space it could produce a
different result.

If this is a problem for your application, the simplest solution is to not
use the package filesystem. It was designed with a developer’s needs in
mind, not necessarily for use in target systems. If your system is a runtime
one, simply not using it is often the best option. If the system is your
development desktop, that may not be practical (even then, for some
applications you might choose to stop the package filesystem, perform your
operations, then start it again).

Hope this isn’t giving you a headache. :slight_smile:

Ok Eric, I understand your meanning. The problem is that the package
filesystem introduce a new problem.
Normally cp allows to not take care of virtual devices.
It’s perfectly justified to not take care of /proc if I want to copy all
directories/files from /.

The problem here, and which differ from the behaviour it would have on
Unix for example, is that a file like /etc/country will be considered in
the same way as /proc/ipstats because of the package filesystem. I just
wonder if it’s a good thing.
I don’t know what POSIX says about that. Maybe cp is right if we just
consider that cp should ignore virtual files or files belonging to
different devices.
The question is “Does a regular file (regular file terminology is
somewhat roundabout here) must be considered as a part of a different
device because it belongs to the package filesystem?”

I didn’t make the test on Unix but is it really justified, for the same
file, to change the behaviour of the copy between ‘cp’ and ‘cp -R’?

regards,
Alain.


Eric Johnson a écrit:

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3E391F13.8050402@icbt.com> …



But you don’t really answer to one question:
Do you now make difference between a virtual device like /dev/mem and a
regular file belonging to fs-pkg like /etc/country in ‘cp -R’ behaviour?




I don’t understand your question, so I’ll just explain a bit more and if
this doesn’t cover what you need to know, perhaps you can rephrase.

With cp -R (in -N mode; i.e. either the default 6.1 behavior or -N with
6.2), cp will ignore (i.e. not copy to the destination) any source files
that reside on a different device from the directory you specify to cp on
the command line. This “different device” could be real or virtual – all
that matters as far as cp is concerned is that the st_dev field differs
between the source file and its parent directory.

Depending on what you are trying to do, this is can be a problem when the
package filesystem is running.

Not only does the package filesystem present lots of files and directories
on virtual devices, but because of pathname unioning, many directories will
exist both physically on the disk as part of the real filesystem and
virtually as part of a package.

/etc is present both virtually as part of multiple packages, and on disk as
part of your physical filesystem

On a typical system /etc resides both on the physical disk (e.g. to contain
/etc/shadow, which is not present in a package) and as part of more than one
package administered by fs-pkg. When you readdir() or ls the directory, or
try to access a file within it, the pathname spaces are merged such that you
seamlessly see and access the combined contents of all the virtual and real
filesystems that ‘own’ /etc or files/dirs within it. When you stat() the
/etc directory itself, you’ll get the information pertaining to just one of
the multiple /etc directories that may overlap in that part of the pathname
space. Which one will you get? Well, typically on a normal Neutrino
development desktop you’d get one of the package filesystem versions, but if
more programs adopted that part of the pathname space it could produce a
different result.

If this is a problem for your application, the simplest solution is to not
use the package filesystem. It was designed with a developer’s needs in
mind, not necessarily for use in target systems. If your system is a runtime
one, simply not using it is often the best option. If the system is your
development desktop, that may not be practical (even then, for some
applications you might choose to stop the package filesystem, perform your
operations, then start it again).

Hope this isn’t giving you a headache. > :slight_smile:

\

The -N behavior (and default behavior under 6.1) is not what POSIX says cp should do. It’s a QNX extension that worked well under QNX 4 (allowing us to copy everything residing on a physical hard drive mounted at /) but is generally not a good thing under the QNX Neutrino RTOS, which is why it was changed in 6.2. Because it’s not POSIX, setting POSIX_STRICT (under QNX 4 and QNX Neutrino 6.1) turns this behavior off.

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message news:3E3A2172.10609@icbt.com
Ok Eric, I understand your meanning. The problem is that the package filesystem introduce a new problem.
Normally cp allows to not take care of virtual devices.
It’s perfectly justified to not take care of /proc if I want to copy all directories/files from /.

The problem here, and which differ from the behaviour it would have on Unix for example, is that a file like /etc/country will be considered in the same way as /proc/ipstats because of the package filesystem. I just wonder if it’s a good thing.
I don’t know what POSIX says about that. Maybe cp is right if we just consider that cp should ignore virtual files or files belonging to different devices.
The question is “Does a regular file (regular file terminology is somewhat roundabout here) must be considered as a part of a different device because it belongs to the package filesystem?”


I didn’t make the test on Unix but is it really justified, for the same file, to change the behaviour of the copy between ‘cp’ and ‘cp -R’?


regards,
Alain.



Eric Johnson a écrit:

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3E391F13.8050402@icbt.com


But you don’t really answer to one question:
Do you now make difference between a virtual device like /dev/mem and a
regular file belonging to fs-pkg like /etc/country in ‘cp -R’ behaviour?



I don’t understand your question, so I’ll just explain a bit more and if
this doesn’t cover what you need to know, perhaps you can rephrase.

With cp -R (in -N mode; i.e. either the default 6.1 behavior or -N with
6.2), cp will ignore (i.e. not copy to the destination) any source files
that reside on a different device from the directory you specify to cp on
the command line. This “different device” could be real or virtual – all
that matters as far as cp is concerned is that the st_dev field differs
between the source file and its parent directory.

Depending on what you are trying to do, this is can be a problem when the
package filesystem is running.

Not only does the package filesystem present lots of files and directories
on virtual devices, but because of pathname unioning, many directories will
exist both physically on the disk as part of the real filesystem and
virtually as part of a package.

/etc is present both virtually as part of multiple packages, and on disk as
part of your physical filesystem

On a typical system /etc resides both on the physical disk (e.g. to contain
/etc/shadow, which is not present in a package) and as part of more than one
package administered by fs-pkg. When you readdir() or ls the directory, or
try to access a file within it, the pathname spaces are merged such that you
seamlessly see and access the combined contents of all the virtual and real
filesystems that ‘own’ /etc or files/dirs within it. When you stat() the
/etc directory itself, you’ll get the information pertaining to just one of
the multiple /etc directories that may overlap in that part of the pathname
space. Which one will you get? Well, typically on a normal Neutrino
development desktop you’d get one of the package filesystem versions, but if
more programs adopted that part of the pathname space it could produce a
different result.

If this is a problem for your application, the simplest solution is to not
use the package filesystem. It was designed with a developer’s needs in
mind, not necessarily for use in target systems. If your system is a runtime
one, simply not using it is often the best option. If the system is your
development desktop, that may not be practical (even then, for some
applications you might choose to stop the package filesystem, perform your
operations, then start it again).

Hope this isn’t giving you a headache. :slight_smile: