Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: SAMBA incompatibilities with VFAT=1 directory names



Manfred Schmidt-Voigt wrote:
> 
> ...
> I started to write you this answer: (If I like to write prosa like "
> %Was#5FSie#5Fschon#5Fimmer#5Fueber#5FSex#5Fwissen#5Fwollten "
> (37,28%overhead)

What's this all about??
I was under the impression that the recording name

  %Was Sie schon immer ueber Sex wissen wollten

would be stored as

  %Was_Sie_schon_immer_ueber_Sex_wissen_wollten

(AFAIK WIndows _can_ handle the '_' character). So what's the deal with
the '#5F'? Are you getting names like that? In that case that would be
a bug in VDR.

> I prefere Staroffice or M$-Word (according to the needs of
> the actual work). But for using the filesystem I try to find something more
> convenient like "recording1", "recording2", ...).

Come on, you can't be serious! When I look at the /video directory from the
plain shell level, I want to be able to identify the various recordings.
You have to admit that a directory like

 %Der_Bulle_von_Tölz
 Die_Harald_Schmidt_Show
 Drama_im_Nordatlantik_Der_Mythos_Titanic
 Familie_Heinz_Becker
 Ladykracher
 Länder_-_Menschen_-_Abenteuer
 Mensch_Markus
 nano
 %Scheibenwischer
 Star_Wars_-_Episode_I:_Die_dunkle_Bedrohung

is a *lot* more useful than something like

 recording1
 recording2
 recording3
 recording4
 recording5
 recording6
 recording7
 recording8
 recording9
 recording10

> But I noticed during
> writing that this is realy, realy difficult to decide what the best way is.
> So forget this point and stay with your system.

I can't imagine *anybody* seriously voting for system using "recording1", "recording2"...
Be honest: do you name your text documents "text1.doc", "text2.doc"...??
How would you know what's inside those files after a few days?

> > > And if you stay
> > > with "old" filenameconvention (ASCII128, 8.3 uppercase(?) alphanumeric
> > > without characters below #20(space) ) you will nearly have no
> > problems with
> > > any foreign system.
> >
> > If Windows had implemented "long filenames" correctly in the first place,
> > we wouldn't be having this discussion.
> 
> Useless discussion! Do you mean, if Windows had implemented "long filenames"
> as UNIX/LINUX  has done it...?? or ...
> Who decides in this artificial world of computers what is right or wrong?

I didn't say "as UNIX/LINUX  has done it" - I just said "correctly".
Remember the problem with the dot at the end of a directory name.
Do you think this is "correct"??

> > > VDR could use than the summary file or whatever to create all
> > that content
> > > for the human reading. As somtimes discussed here it could be from a XML
> > > file or any other structured datafile. But please keep it in a
> > flat ASCII
> > > file again for compatibility.
> >
> > I didn't choose Linux as "my" operating system, where I can store
> > a recording's
> > name in its plain directory name, just to throw all this away because some
> > crappy, broken, so called "operating system" from Redmond is
> > unable to deal with
> > directory names correctly. Encoding characters that cause
> > problems under Windoze
> > is as far as I will go - if you want anything else, you can
> > always implement that
> > yourself. However, the core VDR source will not do that as
> > default. Linux can
> > handle any directory names, so why shouldn't VDR use this?
> >
> 
> Hey, I don't want to stomp you on your feet. This were some thoughts about
> making the filesystem more clean.

"More clean"??? How can it be any more clean than with simply using the
recording's name as the directory name?

> If this is such a big deal and really a
> core functionality than please leave it as it is.

Rest assured I will!

> > > Maybe there are real RFC's for directory and filenames and if
> > they are there
> > > lets use them without (tricksing) doing everything what is possible.
> >
> > There is no "tricksing" when VDR creates a directory with a plain
> > text name.
> > It's neither VDR's nor Linux's fault that Windoze is broken.
> >
> > Gee, a few days ago I said to myself I wouldn't get involved in
> > discussions
> > about Windoze deficiencies any more. But when reading messages
> > like this one,
> > requiring every software to limit itself to the capabilities (or
> > lack thereof)
> > of Windoze, I just can't hold back... Why don't people march
> > towards Redmond
> > and request M$ to fix *their* product?
> >
> 
> Because I'm not interested to get 1 bugfix and 10 new bugs. I'm more
> interested in helping and trying to improve a software like VDR. Maybe my
> thaughts are not helpful and that it is not on top of your prioritylist that
> also people which uses other OS's because of many different reasons can use
> your program. But I hope that my remarks haven't hurt you too much.

That's exactly what the VFAT option is there for: allowing people who want
to access VDR recordings with Windows to do so! It's not VDR's or my fault
that Windows can't handle several characters in file names, and VDR does
provide means to work around this. But crippling VDR by requesting it to
use silly 8.3 filenames and storing the actual recording name in some file,
just because "her majesty Windoze" is too dumb to handle real file names
is not going to happen. I have absolutely no problem with mapping or converting
characters in a way that allows Windows to access VDR files. But the recording's
name will remain stored in the directory name.

As always: it's open source - you can change it in whatever way you like!
Make it use "recording1", "recording2" etc. and be happy - it's a free world!

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________



Home | Main Index | Thread Index