> 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.
Wont that just cause interoperability issues?
We do all of those except : already, if it wasn't for the existing files which are all going to have :'s in them, and version issues, i'd just add it to the list. The filenames generated are used all over the place so it would be impractical to have fallback code everywhere, I guess we could rename/copy all the filenames in some upgrade step though (just thinking aloud).Here is the current list of invalid characters we check for Windows clients. *\\/?<>|\":
Not going to help real windows based backends though.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...
While you're here, slightly OT, I noticed when using smbmount that seek(0, END) failed on that filesystem (it was from some netware box i think). Is that the server end? Is smbmount the way this is done? Should all the 'normal' filesystem calls/semantics work on such a filesystem, e.g. things like files existing after they're unlinked if they're still open, etc.
--
|
<<attachment: zed-48.small.jpg>>
