On 16 Feb., 23:15, Tim Newsham <tim.news...@gmail.com> wrote:
> It was reported (I forget by who) that renaming wasn't working in ninefs.
that would have been me :)
> I looked into it and it was due to rename trying to do an open first and
> only doing the rename after getting certain error codes. Ninefs wasn't
> returning a proper error. Overall error reporting is still really weak and
> needs work, but I fixed up this case. Rename should work fine in the
> latest SVN code. Note, you'll need to update to the latest npfs, too,
...
That is very good news. Sooner or later I will try to build ninefs
from sources
and try to be of a little help. If you get to build a binary before
"sooner" (march),
please let me know, to test it directly.
Regards,
Jorge-León
Unofficial binary lets me rename files and folders. But it does not
allow me
to create files or folders with spaces in them.
Regards,
Jorge-León
On 17 Feb., 22:13, Tim Newsham <tim.news...@gmail.com> wrote:
> An unofficial binary is athttp://www.thenewsh.com/~newsham/x/ninefs.exe.
> Let me know if you have any problems with it.
>
doing:
% touch 'xx xx'
inside the plan9 console gives me the same error message:
...bad character in file name
as with ninefs.exe.
This aparently outrules a plan9 file server as a backup storage for
windows, where
spaces in file and directory names are notorious, starting with 'New
Folder' and
'New Textdocument.txt' as default names for creating a ... well new
folder etc.
Will start to read plan9 manuals to find rationale or explanation
about (no) spaces
in filenames.
Regards
Jorge-León
On 23 Feb., 01:57, Tim Newsham <tim.news...@gmail.com> wrote:
> Can you create files and folders with spaces in them without using ninefs?
>
Did some homework googling:
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
leads me to this post on the plan9 mailing list:
http://9fans.net/archive/1998/04/22
Where Tom Duff tells us why spaces in file names are not allowed.
Interestingly the actual intro(5) man pages does not say so:
... Plan 9 names may contain any printable character (that is,
any character outside hexadecimal 00–1F and 80–9F)
except slash.) ..."
Since spaces are common in MS-Windows, i propose to make a
workaround in ninefs, translating spaces in Windows filenames
into some allowed character in 9fs and vice versa.
Two approaches occur to me:
1. use a character which is not allowed in Windows filenames,
examples: \ ?
Advantage: just need to flip the respective character, filename
string
does not grow
2. use the non-breakable space UNICODE character as proposed somewhere
in the above essay.
Advantage: filenames look the same on Windows and on Plan9
Disadvantage: non-breakable space characater could be a valid
character in
Windows too.
On length of filenames:
The essay says, that MS-Windows Kernel allows a maximum of 259
characters
in a path. The length of a path/filename in 9fs is limited by the
negotiated
maximum message length. Maybe we could suppose that it is always
longer
then 259 characters, and rely eventually on the error message by the
server.
Best Regards,
Jorge-León
On 24 Feb., 06:19, Tim Newsham <tim.news...@gmail.com> wrote:
> acme-sac (perhaps all of inferno?) renames spaces to some
> underscore-like space character in all filenames. Perhaps I could
> do something like that in ninefs, as an option or as default behavior.
> Though there are bound to be other semantic differences, like different
> path length restrictions or case-sensitive vs. case-insensitive semantics.
> Perhaps the windows filesystem driver isn't the best place to handle all
> of that. Are there any existing layered approaches in plan9 that can
> accommodate these things?
>
Interestingly the actual intro(5) man pages does not say so:
... Plan 9 names may contain any printable character (that is,
any character outside hexadecimal 00–1F and 80–9F)
except slash.) ..."
Since spaces are common in MS-Windows, i propose to make a
workaround in ninefs, translating spaces in Windows filenames
into some allowed character in 9fs and vice versa.
On length of filenames:
The essay says, that MS-Windows Kernel allows a maximum of 259
characters
in a path. The length of a path/filename in 9fs is limited by the
negotiated
maximum message length. Maybe we could suppose that it is always
longer
then 259 characters, and rely eventually on the error message by the
server.
Jorge-León