Yes, "." and ".." are both there, after an ls -a /mnt/heg/data command.

Interesting... there's no entry for "." in /mnt/heg/data.  That can't
be good.

Does "ls -a /mnt/heg/data" show an entry for "."?  Or does it just
show ".." and the folders under "data"?  (I expect it does show ".",
but I want to be sure.)

Here are the rsponses:

(file-name-all-completions "" "/mnt/heg")
("../" "./")


(file-name-all-completions "" "/mnt/heg/data")
("../")


(find-file-name-handler "/mnt/heg"
			'file-name-all-completions)
nil


(find-file-name-handler "/mnt/heg/data"
			'file-name-all-completions)
nil

The /mnt/heg/folders are mounted. ls -lt /mnt/heg/data yields a list of
about 20 folders. 

I do not know if I already provided it, but here are the contents of
.xemacs/custom.el:

(custom-set-variables
 '(desktop-enable t nil (desktop))
 '(display-time-24hr-format t)
 '(fill-column 70)
 '(filladapt-turn-on-mode-hooks (quote (text-mode-hook)))
 '(gnuserv-frame (quote gnuserv-main-frame-function)))


(custom-set-faces
 '(default ((t (:size "15pt" :family "Liberation.Mono" :foreground
"black" :background "wheat"))) t))


;; (custom-set-faces
;;  '(default ((t (:size "15pt" :family "Liberation.Mono" :foreground
"wheat" :background "darkslategrey"))) t))


Thanks.

I was going through some old email and got reminded that XEmacs has a
file handler facility, and that it might be getting in the way.

What do these expressions yield?

(file-name-all-completions "" "/mnt/heg")

(file-name-all-completions "" "/mnt/heg/data")

(find-file-name-handler "/mnt/heg"
			'file-name-all-completions)

(find-file-name-handler "/mnt/heg/data"
			'file-name-all-completions)

(These easiest way to evaluate each of them is to copy the expression
into the *scratch* buffer, click after the ")" and then press C-j.)

I have been out of town without access to the LAN where xemacs has
difficulty. One point that may be worth mentioning is that I mount these
windows shares with a script in a terminal, using the mount command, and
my Windows username is different from my Linux username.  Nevertheless,
all other linux programs (Open Office, gedit, nautilus, mc) can read and
write to these windows shares. 

mount -t cifs //xxx.xxx.xxx.xxx/data   /mnt/heg/data    -o
user=domain/windows_user%password,uid=linux_user,gid=linux_user,rw

The strace output shows XEmacs successfully reading one of the mounted
directories (/mnt/heg/data) and statting the files in the directory.

Later, it shows XEmacs successfully reading /mnt/heg and successfully
statting the mount point directories.

  open("/mnt/heg",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 6
  getdents(6, /* 6 entries */, 32768)     = 104
  lstat64("/mnt/heg/.", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
  lstat64("/mnt/heg/..", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
  lstat64("/mnt/heg/data", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
  lstat64("/mnt/heg/sas", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
  lstat64("/mnt/heg/maxtor", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
  lstat64("/mnt/heg/users", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
  getdents(6, /* 0 entries */, 32768)     = 0
  close(6)                                = 0

At line 2627 of the trace, things get weird.  XEmacs opens /mnt/heg
and starts to go through the mount point directories again, but it
only stats the . and .. entries.

  open("/mnt/heg",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 6
  getdents(6, /* 6 entries */, 32768)     = 104
  lstat64("/mnt/heg/.", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
  lstat64("/mnt/heg/..", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
  getdents(6, /* 0 entries */, 32768)     = 0
  close(6)                                = 0

This repeats a few times.

At line 3596 it shows Mark trying to do something with one of the
files under /mnt/heg/data.  This is a file that XEmacs was able to
stat earlier in the trace.

  stat64("/mnt/heg/data/testing.txt", {st_mode=S_IFREG|0755,
st_size=101, ...}) = 0
  readlink("/mnt", 0xbfa69fbc, 4095)      = -1 EINVAL (Invalid argument)
  readlink("/mnt/heg", 0xbfa69fbc, 4095)  = -1 EINVAL (Invalid argument)
  readlink("/mnt/heg/data", 0xbfa69fbc, 4095) = -1 EINVAL (Invalid argument)
  readlink("/mnt/heg/data/testing.txt", 0xbfa69fbc, 4095) = -1 EINVAL
(Invalid argument)
  lstat64("/mnt/heg/data/testing.txt", {st_mode=S_IFREG|0755,
st_size=101, ...}) = 0
  stat64("/mnt/heg/data/testing.txt", {st_mode=S_IFREG|0755,
st_size=101, ...}) = 0
  readlink("/mnt", 0xbfa6108c, 4095)      = -1 EINVAL (Invalid argument)
  readlink("/mnt/heg", 0xbfa6108c, 4095)  = -1 EINVAL (Invalid argument)
  readlink("/mnt/heg/data", 0xbfa6108c, 4095) = -1 EINVAL (Invalid argument)
  readlink("/mnt/heg/data/testing.txt", 0xbfa6108c, 4095) = -1 EINVAL
(Invalid argument)
  readlink("/mnt/heg/data/.#testing.txt", 0x9544810, 100) = -1 ENOENT
(No such file or directory)
  readlink("/mnt/heg/data/.#testing.txt", 0x9544810, 100) = -1 ENOENT
(No such file or directory)
  stat64("/mnt/heg/data/testing.txt", {st_mode=S_IFREG|0755,
st_size=101, ...}) = 0
  ...
  access("/mnt/heg/data/", W_OK)          = 0
  lstat64("/mnt/heg/data/testing.txt", {st_mode=S_IFREG|0755,
st_size=101, ...}) = 0
  stat64("/mnt/heg/data/", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
  ...
  access("/mnt/heg/data/", W_OK)          = 0
  stat64("/mnt/heg/data/#testing.txt#", 0xbfa6ca0c) = -1 ENOENT (No such
file or directory)
  ...
  stat64("/mnt/heg/data/", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
  ...
  access("/mnt/heg/data/", W_OK)          = 0

The rest of the trace output looks like XEmacs talking to the X
server.

So XEmacs checks for the presence of a lock file and a recovery file,
finding neither.  But it never opens the file.  In fact, the only
open() calls in the trace are for /mnt/heg/data and /mnt/heg.

I don't think the permissions are out of the ordinary, as all other
linux programs I have tried can access the mounted folders.  Thank you
for the suggestion to try 21.5 but it is not available in the ubuntu
9.10 main release or backports.  Do you know if 21.5 will be in ubuntu 4.11?

This is possibly due to Unix interpretation of DOS/Windows permissions.

Make sure that files and directories along the path are *not* set to
hidden, etc.

You might also want to try recent 21.5; some (unsystematic) work has
been done to improve permission sematics on Windows.

Apparently I am unable to load the trace file, or it failed... twice.
I'll try again. I've rerun strace making a smaller version.

csv file opened fine when copied to local drive. Mount info

mount -l -t cifs
//192.168.0.10/data on /mnt/heg/data type cifs (rw,mand)
//192.168.0.10/users on /mnt/heg/users type cifs (rw,mand)
//192.168.0.10/sas drive on /mnt/heg/sas type cifs (rw,mand)
//192.168.0.10/Maxtor on /mnt/heg/maxtor type cifs (rw,mand)

Thanks.

The "Cannot open load file" issue is probably unrelated to your CIFS
mount.  If you copy the .csv file to a local filesystem, do you get
the same error when you try to view it?

For the other problems, it'd be helpful to get strace output.  That
is, determine the process ID of your xemacs using ps, and plug that
into the command

    strace -p <process ID>

Then try the operations that fail, and post the corresponding strace
output.

Just to clarify, I had about 4 different shares mounted at /mnt/heg.
dired sees them all, but moving into any of them produces the file not
found and directory write protected comment, and returns a blank window. 

I can view all these shares from a gnome-terminal, mc, and nautilus.

Just tried dired. This can read the initial mounted node /mnt/heg/data
(and others mounted at /mnt/heg), but moving into this folder yields:
file not found and directory write protected.

No errors. I am using Ctl-X Ctl-F to open a file. I then type /mnt/heg,
which is the particular point I am using to mount the file system, and
hit tab. the possible completions I get are . and ..

If I manually specify the entire path to a filename & the filename (in
this case hyprices.csv was the filename), I get the error:
File mode specification error: (file-error "Cannot open load file"
"csv-mode").

The previous test involved a long path with spaces in the file name,
that I made with Ctl-Q <space>.

I also created a testing.txt test file at /mnt/heg/data/SRAM, - which is
a shorter path that is actually mounted. I can see & view the file in
mc. If in the Find File dialog I put /mnt/heg/data/SRAM and hit Tab, I
get [no match]. If I specify the full path/filename, I get (new file),
even though the file exists.

If I edit this "new file" and save it, it overwrites the old one. I then
killed the buffer. When I tried to reopen it, I get (new file) again. 

The bottom line is that xemacs is able to write, but not read the share.

What happens when you try to access the files?  If you get an error
message, what does the message say?

I use ubuntu 9.10, xemacs (nomule) 21.4.22. I am running on a laptop
that connects to various file shares at different locations. I use the
command

mount -t cifs 
 
to mount specific windows shares under /mnt.  I can read/write these
shares from every program that I have tried - except xemacs.  Am I
missing a package? Thanks.