Network Save bug must be fixed.

[Wulfy]

Hi,

Im writing to this group because people who actually know the
internals can probably help.
This is not an isolated problem, I have been researching it for a
while and there is no response.
People just give up and walk away from Tiddly.
Tiddly has a potential for greater adoption in the workplace but it
fails abysmaly on SOME networks.

I have been struggling for the last few days to fix the "It's not
possible to save changes. Possible reasons include:..."

I have gone as far as to research the code and find that
loadFile(localPath); returns null.
Now clearly that is not the case, so with some browser (IE6.0+) and
networks (XP, NTFS) this is an issue.
I have gone through the code and though my programming days are long
over, I find the code to save to be particularly sloppy. I dont know
whether its the nature of JAVA or the organic development of Tiddly.
I tried to hack the code so I hardcode my network path to avoid the
error, but it only breaks things further down.

Why cant there be 'SaveMyStuff(Path,Flag)' code? Why all this
errorchecking and acrobatics that breaks across platforms?

var localPath = getLocalPath(originalPath);
// Load the original file
var original = ******loadFile(localPath);******** <--- BAD BAD BAD...
Breaks badly.
if(original == null) {
alert(config.messages.cantSaveError);
if(store.tiddlerExists(config.messages.saveInstructions))
story.displayTiddler(null,config.messages.saveInstructions);
return;

[Martin Budden]

Could you give a bit more detail about when saving fails. Which
browser and OS are you using? Does saving fail all the time, or just
sometimes? Any detail you can give will help solve the problem.

Martin

2008/4/28 Wulfy <wul...@gmail.com>:

[Eric Shulman]

> I have gone as far as to research the code and find that
> loadFile(localPath); returns null.
> Now clearly that is not the case, so with some browser (IE6.0+) and
> networks (XP, NTFS) this is an issue.
> I have gone through the code and though my programming days are long
> over, I find the code to save to be particularly sloppy. I dont know
> whether its the nature of JAVA or the organic development of Tiddly.

> Why cant there be 'SaveMyStuff(Path,Flag)' code? Why all this
> errorchecking and acrobatics that breaks across platforms?

The language is "Javascript"... not "Java". Although they share the
same frist four letters, these are two entirely different languages.
Javascript is an interpreted language, parsed and processed by a
'javascript engine' compiled within each browser. "Java" is compiled
language, processed by an external application (the Sun Java
runtime). Browsers can embed Java via the <applet> tag, and can even
invoke Java-defined APIs from Javascript, but all processing occurs
outside of the browser itself.

Note that, while javascript is *supposed* to conform to the W3C
ECMAScript standards, each browser contains it own implementation of a
'javascript engine', which unfortunately results in some extremely
subtle variations in language interpretation.

As a result, certain functions must be coded to 'sniff' the specific
browser, generally by looking for various text within the browser-
defined "navigator.userAgent" string. However, testing the
'userAgent' string is not absolutely reliable. This is because the
value contained in any given browser implementation can be
deliberately 'spoofed' so that various alternative browsers can report
themselves to be, for example, "IE compatible", when in fact, they are
not truly 100% compatible in all ways (most notably their file I/O
abilities).

Another approach is to forego direct browser detection and wrap
certain functional usage in "try...catch" blocks so that when the most
common usage throws an error, it can fallback to more browser-specific
usage and retry until, hopefully, one of the alternatives succeeds.

In addition to variations in Javascript implementations, there are
also variations in browser/OS handling of path/file naming
conventions. Most notoriously, IE uses Windows-native "\" syntax as a
path separator in URIs, rather than the more generic "/" separator
used throughout the web. Similarly, IE's 'location' field allows
Windows-native filesystem references instead of the W3C standard URI
(file://).

As a result, the code for getLocalPath() and saveFile() isn't
'sloppy'... it's just trying to cope with a great deal of platform and
browser specific variations in filesystem naming conventions and
handling.

> I tried to hack the code so I hardcode my network path to avoid the
> error, but it only breaks things further down.

> var localPath = getLocalPath(originalPath);
> // Load the original file
> var original = ******loadFile(localPath);******** <--- BAD BAD BAD...

Although the problem *might* be in the saveFile() handling, it is most
probably in the getLocalPath() processing. This function starts with
the browser-supplied "document.location" value (which is generally the
same as what is displayed in the browser's location field), and then
attempts to identify and translate that value into a platform-specific
path/file reference.

I suspect that your attempts to hardcode your network path were not
correctly implemented... undoubtedly due to your acknowledge
deficiencies regarding programming in Javascript as well as the
subtleties of cross-browser, cross-platform coding (especially in
regard to file I/O).

In order to identify and implement any solution to your problem, the
first step would be for you to provide more precise details about the
specific environment in which you are operating:

* What browser and version are you using?
* What version of TiddlyWiki are you using?
* How are you mounting your network drives (e.g., are you assigning a
drive letter?)
and, most important:
* What is the *exact* URI that the browser reports?
* What 'hardcoded' path(s) did you actually attempt?

Hopefully, with enough details, it *might* be possible to arrive at a
solution to address your particular environment and filesystem usage,
though there is no guarantee that such a solution (if any) would be
robust enough for general use in other environments.

-e
Eric Shulman
TiddlyTools / ELS Design Studios

[Paul Downey]

Hi Eric!

> Note that, while javascript is *supposed* to conform to the W3C
> ECMAScript standards,

Which W3C ECMAScript standards?

Paul
--
http://blog.whatfettle.com

[Eric Shulman]

> > Note that, while javascript is *supposed* to conform to the W3C
> > ECMAScript standards,
>
> Which W3C ECMAScript standards?

Actually, it's not a W3C standard... it is, of course, ECMA (European
Computer Manufacturers Association) that has defined the spec:

http://www.ecma-international.org/publications/standards/Ecma-262.htm

-e

[FND]

Thanks for the efforts you've put into researching and reporting this,
Wulfy.
However, as Eric has explained, it's not sloppy code, but
platform-specific requirements at work.
Nevertheless, I agree that this needs to be fixed ASAP, so I'm looking
forward to getting more details for further analysis.

>> Which W3C ECMAScript standards?
>
> Actually, it's not a W3C standard... it is, of course, ECMA (European
> Computer Manufacturers Association) that has defined the spec

While we're being nit-picky, isn't "extremely subtle" a bit of an oxymoron?
(Plenty of room to be nit-picky about that very statement as well, of
course - but let's not get too far off topic here... )

-- F.

[Eric Shulman]

> ...isn't "extremely subtle" a bit of an oxymoron?

Here's some definitions of "subtle"
difficult to perceive or understand
faint and mysterious
requiring mental acuteness, penetration, or discernment
insidious in operation

and for "extreme":
of a character or kind farthest removed from the ordinary or average
exceeding the bounds of moderation

Thus, in context, "extremely subtle" emphasizes that browser-based
differences in Javascript implementations are even more difficult,
mysterious, and insidious than merely just "subtle". (Somehow,
"insidious" seems especially apt when applied to the peculiarities of
Internet Exploder ;-)

-e

[Wulfy]

Wow, amazing response. I have faith that we can get through this
one...
Here is the information requested:

* What browser and version are you using?

IE 6.0.2900.2180 xpSP2 070227-2254

* What version of TiddlyWiki are you using?

2.3.0
Though I tried the latest Beta, with similar results.

* How are you mounting your network drives (e.g., are you assigning a
drive letter?)

Scripted mount: (It’s a corporate network)
O:\Regional IT[obfuscate]Project files\ProjectLog[obfuscate].html
I also have a scripted mount to drive R: so I can mount it on any
memory stick.
net use R: "\\[obfuscate]\ [obfuscate]\ITServices\IT[obfuscate]Project
\Regional IT[obfuscate]
* and, most important:

What is the *exact* URI that the browser reports?

R:\ProjectLog[Obfuscate].html (Local Intranet zone)
and
file:///R:/ProjectLog[Obfuscate].html

* What 'hardcoded' path(s) did you actually attempt?

‘R:\Projectlog[Obfuscate].html and file:///vairant /’ – But I got into
strife, Im not a Javascript programmer. I can barely read the code.
Interestingly I reverted the browser to factory defaults, and now I
can not even edit the file saved on C:, where previously I could. 0_0.
With Debug enabled. Local C: drive fail (opening url is C:…)
Line number:
9167
‘Bad file name or number’
URL: file://C:\Documents and settings\path to my documents....
The network save does not appear to trigger the debugger.

[Wulfy]

<crickets>?

> > TiddlyTools / ELS Design Studios- Hide quoted text -
>
> - Show quoted text -

[Eric Shulman]

> <crickets>?

The example you gave:
file:///R:/ProjectLog.html
is converted by getLocalPath() to
R:\ProjectLog.html
which appears to be the correct path/file to be written, so it is
unclear why it doesn't work.

However, IE6 is fairly old, and IE7 (the current version) is generally
more robust. If you can upgrade, then the problem might simply
disappear. However, because you are in an IT-controlled work
environment, upgrading might not be an option.

Unfortunately, it's really difficult to debug these things from afar,
and without having direct access to your specific setup, I can't
immediately think of any specific. But I'll keep pondering the
problem and hopefully can come up with some suggestions for
experiments you could try...

... and perhaps some of the other TiddlyWizards will some other
ideas...

Be patient... these things take time...

-e

[Wulfy]

Thanks guys.
IE6 is the corporate platform.

In line with the 'guerrilla wiki' approach, I got Firefox on a stick
which actually works, works well on the network location.
So, for me, problem is solved.
Hopefully it wont put off too many people on a config similar to mine.

Also, I *DID* have to change some references on my tiddlywiki from 'R:
\' to 'file://R:\' for them to work in firefox.

I blame IE6 for this issue.