Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Linux] May device identifier be changed without reboot?

39 views
Skip to first unread message

Alex Vinokur

unread,
Jan 4, 2012, 11:53:24 PM1/4/12
to
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

Rainer Weikusat

unread,
Jan 5, 2012, 11:01:54 AM1/5/12
to
Alex Vinokur <alex.v...@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?

Barry Margolin

unread,
Jan 5, 2012, 9:24:15 PM1/5/12
to
In article <87y5tmm...@sapphire.mobileactivedefense.com>,
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, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Tim Roberts

unread,
Jan 6, 2012, 1:43:35 AM1/6/12
to
Alex Vinokur <alex.v...@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, ti...@probo.com
Providenza & Boekelheide, Inc.

Jorgen Grahn

unread,
Jan 6, 2012, 2:02:16 AM1/6/12
to
On Fri, 2012-01-06, Barry Margolin wrote:
> In article <87y5tmm...@sapphire.mobileactivedefense.com>,
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>
>> Alex Vinokur <alex.v...@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 .

Alex Vinokur

unread,
Jan 6, 2012, 3:21:25 AM1/6/12
to


"Jorgen Grahn" wrote in message
news:slrnjgd73m.1...@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

unread,
Jan 6, 2012, 3:14:24 AM1/6/12
to
On Jan 6, 9:02 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Fri, 2012-01-06, Barry Margolin wrote:
> > In article <87y5tmm93h....@sapphire.mobileactivedefense.com>,
> >  Rainer 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.  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   .

Richard Kettlewell

unread,
Jan 6, 2012, 4:22:34 AM1/6/12
to
Alex Vinokur <alex.v...@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/

Alex Vinokur

unread,
Jan 6, 2012, 4:34:41 AM1/6/12
to


"Richard Kettlewell" wrote in message
news:87ehvdj...@araminta.anjou.terraraq.org.uk...
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



Barry Margolin

unread,
Jan 6, 2012, 7:57:48 AM1/6/12
to
In article <je6f7t$4uv$1...@speranza.aioe.org>,
"Alex Vinokur" <ale...@users.sourceforge.net> wrote:

> "Richard Kettlewell" wrote in message
> news:87ehvdj...@araminta.anjou.terraraq.org.uk...
>
> > Alex Vinokur <alex.v...@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?

Alex Vinokur

unread,
Jan 6, 2012, 9:46:02 AM1/6/12
to
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





Kaz Kylheku

unread,
Jan 6, 2012, 11:06:23 AM1/6/12
to
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 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).

Alex Vinokur

unread,
Jan 6, 2012, 1:17:46 PM1/6/12
to
On Jan 6, 6:06 pm, 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 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.
>
In the case described be me the keys are from the same reboot, and
they can differ.

Alex Vinokur

unread,
Jan 8, 2012, 1:55:30 AM1/8/12
to
On Jan 6, 4:46 pm, "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/browse_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
0 new messages