This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

trailing dots and spaces on Samba


Hi,


last week I created the workaround to transpose leading spaces and
trailing dots and spaces in filenames into the UNICODE private use area
on filesystems only supporting filenames following DOS rules.  At least
via PM I got notice that that workaround I created for NetApp and NWFS
filesystems works fine on NetApp.

This morning it occured to me that the workaround might make sense on
Samba as well.  Samba has two possible strategies with such filenames.
Either these names are ignored and a readdir() just doesn't see these
files at all ("mangled names = no"), or the filenames get mangled.

The case that we never see such a file is not very interesting, but
if mangling is on, here's how it looks like:

  cygwin$ echo foo > abc.
  cygwin$ ls -b
  AZIJUG~F
  cygwin$ cat abc.
  foo

On the POSIX system Samba is running on, the file looks normal:

  samba$ ls -b
  abc.

If we change that to use the aforementioned workaround, the result
would look like this:

  cygwin$ echo foo > abc.
  cygwin$ ls -b
  abc.

And on Samba:

  samba$ ls -b
  abc\357\200\256

So, what are the pros and cons?

For the current solution speaks the fact that "abc." refers to the same
file on both systems, on the Windows client as well as on the Samba
server.
For the workaround speaks that readdir() on Cygwin returns the correct
filename from the Cygwin user's perspective.

What't more important?  I'm not sure.  And, shouldn't the user have
a way to decide that for herself?

The deeper problem is that the filesystem recognition is getting more
and more complicated.  Every shortcoming of YA filesystem requires to
change Cygwin to cope with that.

So I was wondering if we shouldn't add more filesystem-specific settings
to the mount options so a user can help herself instead of having to
wait for us to fix Cygwin.  After all, on Linux every filesystem invents
its own mount options, too, as it goes along.

For the above case, a mount option "dos" would come in handy, and an
option "ihash" could be used for unrecognized filesystems which have no
trustable inode numbers.  These are the two more common cases and a
good start, imho.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]