The directory that wasn't?

I’ve just seen something very odd, and was wondering if anyone else had
seen this. On a QNX 4.25E machine, I created a directory yesterday and
copied some files into it. This morning, I attempted to retrieve those
files. But there was a problem: the directory had lost it’s directory
attribute. That is, an ‘ls -l’ shows:

-rwxr-xr-x 1 root root 4096 Aug 02 08:11 test

It’s the right size for the directory, and if I open it in an editor it
looks like a directory. But it just seems to have lost the ‘d’
attribute. A ‘chkfsys -u’ reports no problems.

We’ve seen weirdnesses like this on this machine before; the hard drive
is slightly suspect, although we’ve run extensive diagnostics and never
found a problem.

My real question: is there any way of getting the file system to think
that this is a directory again? The contents aren’t really important,
I’m just curious.

Josh Hamacher
FAAC Incorporated

Josh Hamacher <hamacher@nospam.faac.com> wrote:

I’ve just seen something very odd, and was wondering if anyone else had
seen this. On a QNX 4.25E machine, I created a directory yesterday and
copied some files into it. This morning, I attempted to retrieve those
files. But there was a problem: the directory had lost it’s directory
attribute. That is, an ‘ls -l’ shows:

-rwxr-xr-x 1 root root 4096 Aug 02 08:11 test

It’s the right size for the directory, and if I open it in an editor it
looks like a directory. But it just seems to have lost the ‘d’
attribute. A ‘chkfsys -u’ reports no problems.

We’ve seen weirdnesses like this on this machine before; the hard drive
is slightly suspect, although we’ve run extensive diagnostics and never
found a problem.

My real question: is there any way of getting the file system to think
that this is a directory again? The contents aren’t really important,
I’m just curious.

There isn’t an easy way.

You’d have to go into the directory entry for the file, which lives
in the parent directory, and file the file attributes and set the
directory bit.

I don’t know of a tool that would do this – but by looking at the
description of the filesystem in the System Architecture guide, along
with the structures in <sys/fsys.h> and <sys/stat.h>, if you needed
to, you could probably figure it out.

As to how it might have happened – that I don’t know. Losing exactly
one bit (which is what marks a file as a directory) is a really strange
thing to have happen.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

I have seen this. It’s very weird and doesn’t happen often.

Wasn’t copying to/from and NFS system involved?

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:aieait$bqe$1@nntp.qnx.com

Josh Hamacher <> hamacher@nospam.faac.com> > wrote:
I’ve just seen something very odd, and was wondering if anyone else had
seen this. On a QNX 4.25E machine, I created a directory yesterday and
copied some files into it. This morning, I attempted to retrieve those
files. But there was a problem: the directory had lost it’s directory
attribute. That is, an ‘ls -l’ shows:

-rwxr-xr-x 1 root root 4096 Aug 02 08:11 test

It’s the right size for the directory, and if I open it in an editor it
looks like a directory. But it just seems to have lost the ‘d’
attribute. A ‘chkfsys -u’ reports no problems.

We’ve seen weirdnesses like this on this machine before; the hard drive
is slightly suspect, although we’ve run extensive diagnostics and never
found a problem.

My real question: is there any way of getting the file system to think
that this is a directory again? The contents aren’t really important,
I’m just curious.

There isn’t an easy way.

You’d have to go into the directory entry for the file, which lives
in the parent directory, and file the file attributes and set the
directory bit.

I don’t know of a tool that would do this – but by looking at the
description of the filesystem in the System Architecture guide, along
with the structures in <sys/fsys.h> and <sys/stat.h>, if you needed
to, you could probably figure it out.

As to how it might have happened – that I don’t know. Losing exactly
one bit (which is what marks a file as a directory) is a really strange
thing to have happen.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

This particulary directory (and its parent) reside on the local hard
drive. The system uses SMBfsys to mount two directories off of an NT
machine, but those are mounted elsewhere. Contents from those
directories are copied to the parent directory of the problem child, though.

I’m just going to shrug this one off and add it to my “unexplained
weirdnesses” file. I’ve had a couple of other odd things happen today -
maybe it’s just bad karma or something.

Josh

I understood that it was a local QNX file system.

My point was that every time I’ve seen this it involved copying data to or
from a networked files system.

It’s miles over my head. I don’t have the source to SMBfsys or NFS
anything. And even if I did I don’t understand what lines of C code could
possible be written to screw up the directory bit in a LOCAL QNX file
system.

As I think about it however, I haven’t seen the problem since upgrading to
TCP/IP version 5.0. What are you running? If 4.?? you might want to
upgrade.

I know it’s a real wicked thing when you risk loosing whole directories.

“Josh Hamacher” <hamacher@NOSPAM.faac.com> wrote in message
news:3D4AC47A.8010907@NOSPAM.faac.com

This particulary directory (and its parent) reside on the local hard
drive. The system uses SMBfsys to mount two directories off of an NT
machine, but those are mounted elsewhere. Contents from those
directories are copied to the parent directory of the problem child,
though.

I’m just going to shrug this one off and add it to my “unexplained
weirdnesses” file. I’ve had a couple of other odd things happen today -
maybe it’s just bad karma or something.

Josh

Unfortunately we have TCP/IP v5.00A. The system in question is a
development setup, but we have 36 essentially identical systems
installed and in heavy use. I’ve never heard of this happening on any
of them.

Josh


Bill Caroselli (Q-TPS) wrote:

I understood that it was a local QNX file system.

My point was that every time I’ve seen this it involved copying data to or
from a networked files system.

It’s miles over my head. I don’t have the source to SMBfsys or NFS
anything. And even if I did I don’t understand what lines of C code could
possible be written to screw up the directory bit in a LOCAL QNX file
system.

As I think about it however, I haven’t seen the problem since upgrading to
TCP/IP version 5.0. What are you running? If 4.?? you might want to
upgrade.

I know it’s a real wicked thing when you risk loosing whole directories.

“Josh Hamacher” <> hamacher@NOSPAM.faac.com> > wrote in message
news:> 3D4AC47A.8010907@NOSPAM.faac.com> …

This particulary directory (and its parent) reside on the local hard
drive. The system uses SMBfsys to mount two directories off of an NT
machine, but those are mounted elsewhere. Contents from those
directories are copied to the parent directory of the problem child,

though.

I’m just going to shrug this one off and add it to my “unexplained
weirdnesses” file. I’ve had a couple of other odd things happen today -
maybe it’s just bad karma or something.

Josh
\

Did you create the directory from a tar archive ?
If yes, the pax utility is buggy when unpacking archives with deep directory
levels.
Same happens here…just some dirs becomes files. My workaround was porting
the gtar to QNX4.
cheers, Peter
“Josh Hamacher” <hamacher@NOSPAM.faac.com> schrieb im Newsbeitrag
news:3D4AE2AD.1050007@NOSPAM.faac.com

Unfortunately we have TCP/IP v5.00A. The system in question is a
development setup, but we have 36 essentially identical systems
installed and in heavy use. I’ve never heard of this happening on any
of them.

Josh


Bill Caroselli (Q-TPS) wrote:
I understood that it was a local QNX file system.

My point was that every time I’ve seen this it involved copying data to
or
from a networked files system.

It’s miles over my head. I don’t have the source to SMBfsys or NFS
anything. And even if I did I don’t understand what lines of C code
could
possible be written to screw up the directory bit in a LOCAL QNX file
system.

As I think about it however, I haven’t seen the problem since upgrading
to
TCP/IP version 5.0. What are you running? If 4.?? you might want to
upgrade.

I know it’s a real wicked thing when you risk loosing whole directories.

“Josh Hamacher” <> hamacher@NOSPAM.faac.com> > wrote in message
news:> 3D4AC47A.8010907@NOSPAM.faac.com> …

This particulary directory (and its parent) reside on the local hard
drive. The system uses SMBfsys to mount two directories off of an NT
machine, but those are mounted elsewhere. Contents from those
directories are copied to the parent directory of the problem child,

though.

I’m just going to shrug this one off and add it to my “unexplained
weirdnesses” file. I’ve had a couple of other odd things happen today -
maybe it’s just bad karma or something.

Josh

\

I figured out what happened. And, unfortunately, the whole thing was a
big misunderstanding on my part. It turns out I had created the
directory, but on a different system (call it system B). At some point,
I then FTP’d some files from system B to system A (the one with the
“phantom” directory). FTP, doing exactly what I had asked but not what
I had expected, created a file on system A that looked like the
directory on system B. I discovered this this morning when I looked at
system B and found the real directory. So, thanks to everyone who tried
to help, but the mystery has been solved by the man with egg on his
face. :slight_smile:

Josh

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:aieait$bqe$1@nntp.qnx.com

I don’t know of a tool that would do this – but by looking at the
description of the filesystem in the System Architecture guide, along
with the structures in <sys/fsys.h> and <sys/stat.h>, if you needed
to, you could probably figure it out.

Tool? Try ‘spatch’. Have the System Architecture guide open to the
appropriate section while you work.

I used to be able to hack the file system without the manual. Maybe I still
can.

As to how it might have happened – that I don’t know. Losing exactly
one bit (which is what marks a file as a directory) is a really strange
thing to have happen.

Indeed. A one-bit ram error, maybe?


Bill Flowers
Clearwater, FL

William A. Flowers <wflowers_NOSPAM@insightcontrol.com> wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:aieait$bqe$> 1@nntp.qnx.com> …
I don’t know of a tool that would do this – but by looking at the
description of the filesystem in the System Architecture guide, along
with the structures in <sys/fsys.h> and <sys/stat.h>, if you needed
to, you could probably figure it out.

Tool? Try ‘spatch’. Have the System Architecture guide open to the
appropriate section while you work.

Sorry, I meant a tool that you could just give a filename to, that
would flip the bit for you.

Of course, spatch would allow you to edit the directory – but it
does require the figuring out that I stated.

I used to be able to hack the file system without the manual.

Yes, but you WROTE the file system…that gives you a slight edge. :slight_smile:

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Geez… Bill Flowers, thats an old name here. Hope you are doing fine.

Regards,

Gabriel Coindreau

“William A. Flowers” <wflowers_NOSPAM@insightcontrol.com> wrote in message
news:airrab$7nd$1@inn.qnx.com

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:aieait$bqe$> 1@nntp.qnx.com> …
I don’t know of a tool that would do this – but by looking at the
description of the filesystem in the System Architecture guide, along
with the structures in <sys/fsys.h> and <sys/stat.h>, if you needed
to, you could probably figure it out.

Tool? Try ‘spatch’. Have the System Architecture guide open to the
appropriate section while you work.

I used to be able to hack the file system without the manual. Maybe I
still
can.

As to how it might have happened – that I don’t know. Losing exactly
one bit (which is what marks a file as a directory) is a really strange
thing to have happen.

Indeed. A one-bit ram error, maybe?


Bill Flowers
Clearwater, FL