Bug in File Transfer - Lenghts of Filename?

Hello!

Just stumbles over the following: I tried to transfer a tiny 60kb pdf file via a perfectly working Spark 2.5.5 <-> Spark 2.5.5 session over Openfire 3.2.0.

The filename has about 80 chars in the form of “file_version_subversion_blabla.pdf” and it did not went trough. The other party accepted the file but then nothing happend. Tried it numerous times during a 15 min chat.

After renaming the file to just “file.pdf” it went through within a second after accepting. Does anybody have troubles with the underscore-char??

Hmm, strange…

Starry

Ping! Anybody has any idea?

Thanks for thinking

Starry

Hello!

Is there anybody out there you encountered the very same problem? As soon as I rename the file to be transferred to “short.pdf” everything works out…

Seems to be a problem with looong names and/or SPACES in the filename…

Bye

Starry

Hello!

Update: Still the exact same behaviour when all Sparks are 2.5.7 or 2.5.8 and Openfire up to 3.3.3.

I really wonder why nobody else suffers beause of this cause nobody even comments on this tread…

Bye

Starry

There is no problem with spaces or underscores with short filenames. But very long file names dont work not only in Spark. Pidgin and Exodus cant receive such files either. Maybe this is a problem in Openfire. Or maybe it’s an intended limitation.

Hello!

Thanks for confirming this one. However the limit seems to be much smaller than one would think, so this happens pretty often!

Especially as there is no error msg or anything else, it simply doees not work…

P.S. As they say The answer is in the source but I am not even close in code reading/understanding to look it up myself

Bye

Starry

Hello!

Could somebody please create a JIRA-Issue to finally test and check what the limitations are for filenames/file sizes, etc. in a pure Jive setup, i.e. Spark and Openfire?

Bye

Starry

Bump!

Are people transferring so few files that it is not as annoying to them as well? We have a very limited succes rate with filenames I do not consider really long like todays “sdr-series-protocol.pdf”. Ok, it is bigger than 8.3 but hey, we are not in the Windows 3.11 days anylonger.

Sad to see, that there is no progress with old bugs/problems like this one…

Bye

Starry

And what was the target folder path for that file? Windows has its own limitations of path length. We are constantly facing problems with that. Cant create long paths with long filenames, it brakes after ~80 chars length in Windows Server 2003!!! A little offtopic, heh Not a 3.11 days, but still not a bright future

Hello!

wroot wrote:And what was the target folder path for that file? Windows has its own limitations of path length. We are constantly facing problems with that. Cant create long paths with long filenames, it brakes after ~80 chars length in Windows Server 2003!!!

Ah, we are getting closer!

When installing Spark it automatically uses this path at my XP machine (yaeh, GERMAN Windows)

C:\Dokumente und Einstellungen[WinAccount]\Spark\user[IM-Account@openfire.domain.com]\download\

WinAccount is my Windows Domain Account on this machine., ofcourse without the brackets…

IM-Account@openfire.domain.cm is my JID

So if this 80byte or so restriction is indeed there, then no wonder at all. Can we agree that this is not a wise choice to use such a directory??

Bye

Starry

You can always change you download folder (say to C:\Downloads, or in My Documents). Try it, we’ll see if it changes anything.

Maybe this is not exactly the right folder for downloads (My Documents would be more appropriate), but you cant guarantee that users wont hit the path limitations hidden in the OS kernel.

http://blogs.msdn.com/tomholl/archive/2007/02/04/enterprise-library-and-the-curs e-of-max-path.aspx

Hello!

wroot wrote:

Maybe this is not exactly the right folder for downloads (My Documents would be more appropriate), http://blogs.msdn.com/tomholl/archive/2007/02/04/enterprise-library-and-the-curs e-of-max-path.aspx

IFAIK this dir IS the default profie location %USERPROFILE% of a German XP install! However the English version is C:\Documents and Settings\ which is not that much shorter… And remember, this is the out of box location when you do a vanilla install of Spark… Maybe that was not a wise joice to make

Thanks for the link; one comment I found pretty interesting:

+I’ve encountered this issue before in

some of the code I’ve written, especially code that relied on the Shell

APIs. I subsequently changed the code to use the Unicode version of

CreateFile (CreateFileW) or the CRT equivalent and prepended the

Unicode escape prefix ("
?"), as per the CreateFile docs, and the

problem goes away. MsBuild should generate scripts with escaped paths.+

If you encounter this in another tool, ask the vendor to fix it properly .

Maybe this is of any help to the devs.

Bye

Starry

Hello!

I know development of Spark somewhat stalled but I could imagine, that at least kicking this into JIRA marks it as an open issue. Maybe someday Spark source code is opened or transferred to the community and …

Bye

Starry

The spark source is available in the SRV. There are other community members working on the code currently, such as WinSrev. I am not 100% certain this is an openfire or spark issue. It very well may be a windows issue.

Hey, so, i did some tests, the results are:

this is a really long document with %$£$& and _underscores and a .pdf success

this is a really long document with.pdf success

document.pdf success

Still confused about what the issue is?

Maybe this is an isolated case.

Hello!

Thanks for the tests. Isolated case? Well, could be.

We are all on WinXP and use 2.5.8 from the Skinning server but not all Clients do have Admin rights on their PCs. Spark was however installed under an Admin account.

What is maybe a little bit unusual is that our server is dual homed, i.e. has TWO NICs with one being on the inside at 192.168.x.y and the other NIC on the Internet with an official IP. However this Linux machine is NOT a router. This was chosen so not to have port forwarding or so on the firewall. Both IPs are known to Openfire setup (entered via admin page) and there are DNS servers on BOTH sides.

So a client on 192.168.x.y resolves the server name to the 192.168. but a raodwarrior or customer from the internet queries the official DNS where the host is also registered. There is NO SRV records or other fancy DNS stuff just a plain host name.

Really strange is the fact, that there are not only problems with useres on different NICs but also file transfer between users both on the inside does not always work correctly.

On a side note, there is IMHO still a VERY old bug in Spark, which let a file transfer fail, when Spark (or Openfiere?) receives ANY other caht packet during the transfer negotiating.

Example: I chat to a user “Hold on, I’ll send you the needed pdf” hit enter and then drag a file into the chat window so Spark can try to send the file out. The other user is happy and responds “Great, thanks alot!”. When the file transfer has not yet started it will fail for sure! At least over here! it looks like this chat packet kills the ongoing negotiation.

When the transfer is already happening there is no problem at all.

Bye

Starry

I’m still very confused about what this issue is.

Are you saying that if a sends b a file and b talks before receiving the file transfer message then the file transfer will fail?

Have you tested this by having no talk messages when sending a file?

Hello!

Exactly this is the case, however this is a SECOND problem and is not directly related why file transfers dont work at all sometimes.

When the recipient of a file transfer chates before the “Transferring” gauge is moving but is still “negotiating/preparing” then it will fail.

Bye

Starry