Re: [Evolution-hackers] Re: [linux-cifs-client] cifs mounted home directory problems
- From: Jeremy Allison <jra samba org>
- To: Not Zed <notzed ximian com>
- Cc: Kenneth MacDonald <kenny holyrood ed ac uk>, evolution-hackers lists ximian com, linux-cifs-client lists samba org, Steve French <smfrench austin rr com>
- Subject: Re: [Evolution-hackers] Re: [linux-cifs-client] cifs mounted home directory problems
- Date: Thu, 9 Dec 2004 18:13:49 -0800
On Fri, Dec 10, 2004 at 09:15:51AM +0800, Not Zed wrote:
>
> On Wed, 2004-12-08 at 22:31 +0000, Kenneth MacDonald wrote:
>
> > I'm Cc'ing this to the evolution-hackers list in case anyone thinks this
> > is important enough from the application side.
>
> Well my initial reaction is "not really". An application using a
> filesystem has to rely on a certain set of semantics, and i believe
> we're just relying on what a posixish filesystem should provide.
> Otherwise we're going to have to use lowest common demoninator - e.g.
> 8.3 dos filenames with no permissions. That sounds practical to me!
>
> It isn't something that can very usefully be made a configure switch
> since it is part of the run-time environment. If you just want to patch
> it yourself you can safely make e_filename_make_safe substitute any
> other characters you want. Changing it in the main codebase is trickier
> since it affects finding existing state files in users installed
> environments, and i don't really want to have to add all this ugly
> workaround/fallback code for this.
>
> Are colons the only character winblows uses itself? What about multiple
> full stops? etc.
You know, I can probably fix this in the smbd server code by detecting
a UNIX client and relaxing the "invalid character" checks for things
like : etc.
Here is the current list of invalid characters we check for Windows
clients.
*\\/?<>|\":
and here are the reserved names we disallow for Windows clients
"AUX", "LOCK$", "CON", "COM1", "COM2", "COM3", "COM4",
"LPT1", "LPT2", "LPT3", "NUL", "PRN"
So for a Linux client I can relax this significantly...
Jeremy.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]