Re: [Samba] folder name screwed up

[Toby Ovod-Everett]

On Wed, Aug 14, 2013 at 06:02:49PM +0200, patrick wrote:
 on my linux box i can see the folder as: 1996 - E.I.N.S.
 on my windows 7 box it is show as: 1MNOXH~A
 
 what about the dot at the end of the folder name?
 
 ah. yes thats the problem. never occoured to me to google for
 period at the end of folder in same
 mangled names = no
 in the config fixes the problem, thx.
 
 hm, should have tested it...now i cant access the folder but it
 shows correctly.
 for now i will just remove the dot at the end, at least i can access
 the folder.

From a Command Prompt against the local file system on a Windows 7 machine:

C:\Users\Toby\Desktopmd Foo.

C:\Users\Toby\Desktopdir Fo*
 Volume in drive C has no label.
 Volume Serial Number is 268D-BDFD

 Directory of C:\Users\Toby\Desktop

08/14/2013  08:10 AMDIR  Foo
   0 File(s)  0 bytes
   1 Dir(s)  74,288,111,616 bytes free

C:\Users\Toby\Desktopcd Foo.

C:\Users\Toby\Desktop\Foocd ..

C:\Users\Toby\Desktoprd Foo

C:\Users\Toby\Desktopmd \\?\C:\Users\Toby\Desktop\Foo.

C:\Users\Toby\Desktopdir Fo*
 Volume in drive C has no label.
 Volume Serial Number is 268D-BDFD

 Directory of C:\Users\Toby\Desktop

08/14/2013  08:11 AMDIR  Foo.
   0 File(s)  0 bytes
   1 Dir(s)  74,287,034,368 bytes free

C:\Users\Toby\Desktopcd Foo.
The system cannot find the path specified.

C:\Users\Toby\Desktopcd \\?\C:\Users\Toby\Desktop\Foo.
'\\?\C:\Users\Toby\Desktop\Foo.'
CMD does not support UNC paths as current directories.

C:\Users\Toby\Desktopdir \\?\C:\Users\Toby\Desktop\Foo.
 Volume in drive \\?\C: has no label.
 Volume Serial Number is 268D-BDFD

 Directory of \\?\C:\Users\Toby\Desktop\Foo

File Not Found

C:\Users\Toby\Desktoprd \\?\C:\Users\Toby\Desktop\Foo.


Windows doesn't really like filenames that end in . - they aren't valid in
the normal filesystem calls.  This is probably due to the whole 8.3 naming
convention history - maybe DOS didn't store the . and simply stored the first
8 chars and the 3 chars for the extension and had a standard of not displaying
the trailing period if the extension was missing.

See http://msdn.microsoft.com/en-us/library/aa365247.aspx#namespaces for some
more information.  It appears that Windows strips trailing periods in normal
calls, and so while it can display the directory with a trailing period, it
can't access it unless you use the \\?\ prefix to escape the name
normalization code and speak directly to the filesystem.  On the other hand,
that means you have to use fully-qualified filenames for everything.

Also note the following spotted in
http://msdn.microsoft.com/en-us/library/aa365247.aspx#naming_conventions:

Do not end a file or directory name with a space or a period. Although the
underlying file system may support such names, the Windows shell and user
interface does not. However, it is acceptable to specify a period as the
first character of a name. For example, .temp.

--Toby Ovod-Everett
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

[Samba] Issues launching files from a Command Prompt

[Toby Ovod-Everett]

Ever since upgrading from Fedora 17 to Fedora 19, which included moving from
Samba 3.* to 4.*, I've had issues opening files from a Windows Command Prompt.

I can open files fine from an Explorer window, but if I drop down to a Command
Prompt and type a file name, that no longer opens the file.  I've done some
poking around and discovered that if I set the execute bit on the files, then
everything works.  That said, I'd rather not set the execute bit on entire
swaths of directory trees, and this didn't seem to be an issue under Samba 3.

I used Procmon.exe to confirm that cmd.exe is definitely requesting
Execute/Traverse on the file and that the response is failing.  This behavior
also has interesting impacts on *.BAT files.  If I don't set the execute bit
(and I'd rather not, since I don't want Unix attempting to execute those
files), I can't launch *.BAT files from Explorer because Explorer checks
Execute/Traverse permissions.  I can, however, run the *.BAT file from a
Command Prompt, because it doesn't check Execute/Traverse!

So basically Windows does inconsistent things with the access permissions it
requests when opening files from a Command Prompt vs. Explorer.

Once again, I didn't have these issues until I migrated from 3.* to 4.*.  In
general, the Windows world generally grants Execute whenever it grants Read
and leaves it up to file extensions to control what runs.  I'd prefer not to
have to mess with the execute bit on the Unix side if I can - my preference is
for that bit to be reserved for controlling whether Unix considers the file to
be executable or not.

I've poked around, but I can't seem to find any setting in smb.conf that lets
me control the mapping from Unix permissions bits to Windows ACLs.  I'd really
like some sort of setting that allows me to say, whenever you see the read
bit turned on, map that to Read and Execute.  It's not so much how the ACLs
display in Windows that matters, since I've tried using nt acl support = no
and the underlying request still gets denied.  It's how Samba responds to the
desired access mask.

Thoughts?


Details:
* Server is running Fedora 19 x86_64 w/ samba-4.0.7-1.fc19.x86_64
* Client is running Windows 7 x64 SP1

Interesting sections from smb.conf:

map archive = no
map hidden = no
map read only = no
map system = no
store dos attributes = yes
unix extensions = no

[homes]
comment = Home Directories
browseable = no
writable = yes
hide files = /Thumbs.db*/desktop.ini/$RECYCLE.BIN/
create mask = 0675
directory mask = 0775
wide links = yes


--Toby Ovod-Everett

-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba