Linux 2.6.18-238.12.1.el5 #1 SMP Sat May 7 20:18:50 EDT 2011 x86_64
x86_64 x86_64 GNU/Linux

May device identifier be changed without reboot?

Thanks

Alex Vinokur <alex.vinokur@gmail.com> writes:
> Linux 2.6.18-238.12.1.el5 #1 SMP Sat May 7 20:18:50 EDT 2011 x86_64
> x86_64 x86_64 GNU/Linux

This is very likely the output of uname -a and it is composed of
multiple pieces of information which can be changed in different ways.
What are you specifically referring to?

In article <87y5tmm93h.fsf@sapphire.mobileactivedefense.com>,
 Rainer Weikusat <rweikusat@mssgmbh.com> wrote:

> Alex Vinokur <alex.vinokur@gmail.com> writes:
> > Linux 2.6.18-238.12.1.el5 #1 SMP Sat May 7 20:18:50 EDT 2011 x86_64
> > x86_64 x86_64 GNU/Linux
> 
> This is very likely the output of uname -a and it is composed of
> multiple pieces of information which can be changed in different ways.
> What are you specifically referring to?

I don't think he was asking anything about that, just providing the 
version of Linux he's using as context.  I.e. his question is "In this 
version of Linux, can a device ID change between reboots?"

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Alex Vinokur <alex.vinokur@gmail.com> wrote:
>
>May device identifier be changed without reboot?

What do you mean by "device identifier"?  That phrase has many different
meanings.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

On Fri, 2012-01-06, Barry Margolin wrote:
> In article <87y5tmm93h.fsf@sapphire.mobileactivedefense.com>,
>  Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
>> Alex Vinokur <alex.vinokur@gmail.com> writes:
>> > Linux 2.6.18-238.12.1.el5 #1 SMP Sat May 7 20:18:50 EDT 2011 x86_64
>> > x86_64 x86_64 GNU/Linux
>> 
>> This is very likely the output of uname -a and it is composed of
>> multiple pieces of information which can be changed in different ways.
>> What are you specifically referring to?
>
> I don't think he was asking anything about that, just providing the 
> version of Linux he's using as context.  I.e. his question is "In this 
> version of Linux, can a device ID change between reboots?"

I think so too. There was a thread here or some other Unix programming
group about such things some weeks ago; possibly you need to find that
one to understand what he's referring to.

Better wait for him to reformulate the question.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

On Jan 6, 9:02=A0am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Fri, 2012-01-06, Barry Margolin wrote:
> > In article <87y5tmm93h....@sapphire.mobileactivedefense.com>,
> > =A0Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
> >> Alex Vinokur <alex.vino...@gmail.com> writes:
> >> > Linux 2.6.18-238.12.1.el5 #1 SMP Sat May 7 20:18:50 EDT 2011 x86_64
> >> > x86_64 x86_64 GNU/Linux
>
> >> This is very likely the output of uname -a and it is composed of
> >> multiple pieces of information which can be changed in different ways.
> >> What are you specifically referring to?
>
> > I don't think he was asking anything about that, just providing the
> > version of Linux he's using as context. =A0I.e. his question is "In thi=
s
> > version of Linux, can a device ID change between reboots?"
>
> I think so too. There was a thread here or some other Unix programming
> group about such things some weeks ago; possibly you need to find that
> one to understand what he's referring to.
>
> Better wait for him to reformulate the question.
>
> /Jorgen
>
> --
> =A0 // Jorgen Grahn <grahn@ =A0Oo =A0o. =A0 . =A0 =A0 .
> \X/ =A0 =A0 snipabacken.se> =A0 O =A0o =A0 .

http://groups.google.com/group/comp.unix.programmer/browse_frm/thread/f309d=
300258ad7a1
http://groups.google.com/group/comp.unix.programmer/msg/9dc05598257bdbb6

May 'st.st_dev of the same file (that wasn't removed)' be changed
between reboots?

Alex

"Jorgen Grahn"  wrote in message 
news:slrnjgd73m.1ls.grahn+nntp@frailea.sa.invalid...

[snipped]

> Better wait for him to reformulate the question.

http://groups.google.com/group/comp.unix.programmer/browse_frm/thread/f309d300258ad7a1

http://groups.google.com/group/comp.unix.programmer/msg/9dc05598257bdbb6

May 'st.st_dev of the same file (that wasn't removed)' be changed between 
reboots?

Alex 

Alex Vinokur <alex.vinokur@gmail.com> writes:
> May 'st.st_dev of the same file (that wasn't removed)' be changed
> between reboots?

Yes, provided you're prepared to stretch "not removed" a bit.

Suppose the file is on one of several external USB hard disks.  Unmount
and detach them all, then re-attach them in a different order.  What was
formerly /dev/sdc may now be /dev/sdd, and so on.  The st_dev of the
file will differ accordingly.

-- 
http://www.greenend.org.uk/rjk/

"Richard Kettlewell"  wrote in message 
news:87ehvdjicl.fsf@araminta.anjou.terraraq.org.uk...

> Alex Vinokur <alex.vinokur@gmail.com> writes:
>> May 'st.st_dev of the same file (that wasn't removed)' be changed
>> between reboots?
>
> Yes, provided you're prepared to stretch "not removed" a bit.
>
> Suppose the file is on one of several external USB hard disks.  Unmount
> and detach them all, then re-attach them in a different order.  What was
> formerly /dev/sdc may now be /dev/sdd, and so on.  The st_dev of the
> file will differ accordingly.



Thanks.

Does it mean the ftok() function has bug in design on Linux?

-------------------------------------------

From 
http://groups.google.com/group/comp.unix.programmer/msg/9dc05598257bdbb6

CentOS glibc-2.5-65.src.rpm source code:
/* sysvipc/ftok.c */
key_t
ftok (pathname, proj_id)
     const char *pathname;
     int proj_id;
{
  struct stat64 st;
  key_t key;


  if (__xstat64 (_STAT_VER, pathname, &st) < 0)
    return (key_t) -1;


  key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16)
         | ((proj_id & 0xff) << 24));


  return key;



}
------------------------------------------

==========================================
From http://linux.about.com/library/cmd/blcmdl3_ftok.htm

The resulting value is the same for all pathnames that name the same file, 
when the same value of proj_id is used.
==========================================

Alex

In article <je6f7t$4uv$1@speranza.aioe.org>,
 "Alex Vinokur" <alexvn@users.sourceforge.net> wrote:

> "Richard Kettlewell"  wrote in message 
> news:87ehvdjicl.fsf@araminta.anjou.terraraq.org.uk...
> 
> > Alex Vinokur <alex.vinokur@gmail.com> writes:
> >> May 'st.st_dev of the same file (that wasn't removed)' be changed
> >> between reboots?
> >
> > Yes, provided you're prepared to stretch "not removed" a bit.
> >
> > Suppose the file is on one of several external USB hard disks.  Unmount
> > and detach them all, then re-attach them in a different order.  What was
> > formerly /dev/sdc may now be /dev/sdd, and so on.  The st_dev of the
> > file will differ accordingly.
> 
> 
> 
> Thanks.
> 
> Does it mean the ftok() function has bug in design on Linux?

.... [code snipped]

> 
> ==========================================
> From http://linux.about.com/library/cmd/blcmdl3_ftok.htm
> 
> The resulting value is the same for all pathnames that name the same file, 
> when the same value of proj_id is used.
> ==========================================

If it's a bug, it may be unavoidable.  If the filesystem is unmounted 
and re-mounted, how is the OS supposed to know that it's the "same" file?

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Hi,

st.st_dev of the same file (that wasn't deleted) may be changed between 
reboots on Linux.
http://groups.google.com/group/comp.unix.programmer/browse_frm/thread/018671b4d364409f

As a result, the ftok() function on Linux may generate different keys for 
the same file (that wasn't deleted) between reboots.
It seems to a bug in design of ftok() on Linux.

Does such a problem exist with ftok() on HP-UX?

Alex

On 2012-01-06, Alex Vinokur <alexvn@users.sourceforge.net> wrote:
> Does it mean the ftok() function has bug in design on Linux?

According to the Single Unix Specification (where the requirement
for ftok comes from: it is not a Linuxism) the ftok function is part of IPC. It
is described as "ftok - generate an IPC key" and declared in the header
<sys/ipc.h>.

IPC objects (shared memory segments, message queues and semaphores) are
volatile; they disappear when the machine is shut down.

In other words, it is not meaningful to try to use a key from a previous
boot of the system to try to find an IPC object.

None of the functions which take a key_t argument such as shmget, msget
and semget, will be able to retrieve anything after a fresh reboot,
no matter what the key_t value is.

I'm afraid that the design of whatever you are writing has a bug (by relying
on ftok to be more/other than an IPC key generator).

On Jan 6, 6:06=A0pm, Kaz Kylheku <k...@kylheku.com> wrote:
> On 2012-01-06, Alex Vinokur <ale...@users.sourceforge.net> wrote:
>
> > Does it mean the ftok() function has bug in design on Linux?
>
> According to the Single Unix Specification (where the requirement
> for ftok comes from: it is not a Linuxism) the ftok function is part of I=
PC. It
> is described as "ftok - generate an IPC key" and declared in the header
> <sys/ipc.h>.
>
> IPC objects (shared memory segments, message queues and semaphores) are
> volatile; they disappear when the machine is shut down.
>
> In other words, it is not meaningful to try to use a key from a previous
> boot of the system to try to find an IPC object.
>
> None of the functions which take a key_t argument such as shmget, msget
> and semget, will be able to retrieve anything after a fresh reboot,
> no matter what the key_t value is.
>
In the case described be me the keys are from the same reboot, and
they can differ.

> I'm afraid that the design of whatever you are writing has a bug (by rely=
ing
> on ftok to be more/other than an IPC key generator).

On Jan 6, 4:46=A0pm, "Alex Vinokur" <ale...@users.sourceforge.net>
wrote:
> Hi,
>
> st.st_dev of the same file (that wasn't deleted) may be changed between
> reboots on Linux.http://groups.google.com/group/comp.unix.programmer/brow=
se_frm/thread...
>
> As a result, the ftok() function on Linux may generate different keys for
> the same file (that wasn't deleted) between reboots.
> It seems to a bug in design of ftok() on Linux.
>
> Does such a problem exist with ftok() on HP-UX?
>
> Alex

See also
http://h30499.www3.hp.com/t5/Languages-and-Scripting/ftok-related-Can-st-st=
-dev-of-the-same-file-be-changed-between/td-p/5441073