Hi Everyone,name
I upgraded to sbbs3.17c (3/1/2019) and I'm still having a small bug when uploading files with the same first 8 characters. The two files are
galgox-imginary_numbers.xm
galgox-pixieplanet.xm
When I do a batch upload and upload the one file galgox-imginary_numbers.xm the short name is GALGOX~1.XM and the long
is stored as usual.
But when I upload galgox-pixieplanet.xm, GALGOX~1.XM becomes the short name for that file as well and then the BBS complains that the file already exists.
When I uploaded these files on vert.synchro.net I didn't have this problems as two different short names were generated for each of the files.
What am I missing in the upgrade? Or is there some maintenance program that I need to run?
Also note that I had this same problem before my upgrade when running 3.16c.
Can someone help me trace through the Baja files? E.g.
cmdkey E
file_batch_section
end_cmd
I don't think the issue I am hainvg is related to my custom shell (whichis
a copy of the renegade clone shell). I tried using the default shell and had the same issue. Also my default shell should be fully upgraded from supb317b. And the bin should have been updated from the dev update3/1/19.
Hi Everyone,
I upgraded to sbbs3.17c (3/1/2019) and I'm still having a small bug when uploading files with the same first 8 characters. The two files are
galgox-imginary_numbers.xm
galgox-pixieplanet.xm
When I do a batch upload and upload the one file galgox-imginary_numbers.xm the short name is GALGOX~1.XM and the long name is stored as usual.
But when I upload galgox-pixieplanet.xm, GALGOX~1.XM becomes the short name for that file as well and then the BBS complains that the file already exists.
When I uploaded these files on vert.synchro.net I didn't have this problems as two different short names were generated for each of the files.
What am I missing in the upgrade?
Or is there some maintenance program that I need to run?
Also note that I had this same problem before my upgrade when running3.16c.
Any insights would be appriciated.
wiki.synchro.net/custom:menu_files?s[]=batch&s[]=menu
so maybe the code that generates the short names for files (e.g. 1234556~1.FIL)
is in -> bat_xfer.cpp
Hmm... I guess I'll look in there now.
What version of Windows are you running? It sounds like Windows is doing something weird with short filenames. If you use "dir /x" on those files, what do you see? This what I see on the files you uploaded here:
Re: Trouble uploading two files with the same first 8.3 chars. AllVers
By: Digital Man to Electrosys on Sat Mar 02 2019 12:50 am
files,What version of Windows are you running? It sounds like Windows is doing something weird with short filenames. If you use "dir /x" on those
what do you see? This what I see on the files you uploaded here:
Im running windows 7 on an oracle VM that runs in ArchLinux.
03/02/2019 02:03 AM 479,046 GALGOX~2.XM galgox-imaginary_numbers.xm 02/17/2019 07:11 AM 24,255 GALGOX~1.XM galgox-pixieplanet.xm
pixieplanet is the one that I uploaded to the board and imaginary_numbers I ftped directly over to the upload folder so I can compare the two. I tried upload the files from a Linux instance of syncterm, but I don't think that will make a different. I tried uploading from windows syncterm as well.
And... on the BBS the short names are reversed?
Re: Trouble uploading two files with the same first 8.3 chars. AllVers
By: Digital Man to Electrosys on Sat Mar 02 2019 06:08 pm
And... on the BBS the short names are reversed?
The second short name is never generated on the BBS. So when I upload the second file the same short name is generated the same as the first file.
In the dir listing its showing -imaginary before -pixie which is what I expect.
It asigned GALGOX~1 to -pixie because I uploaded that one first in this particular test case.
GALGOX~2 is never assigned on the BBS. So I'm not sure I'm actually able to answer your question.
And... on the BBS the short names are reversed?
The second short name is never generated on the BBS. So when I upload
the second file the same short name is generated the same as the first
file.
In the dir listing its showing -imaginary before -pixie which is what
I expect.
It asigned GALGOX~1 to -pixie because I uploaded that one first in
this particular test case.
GALGOX~2 is never assigned on the BBS. So I'm not sure I'm actually
able to
answer your question.
When you list the files on theBBS, it shows the short names and the long names. Are they reversed?
Re: Trouble uploading two files with the same first 8.3 chars. AllVers
By: Digital Man to Electrosys on Sun Mar 03 2019 03:45 pm
isAnd... on the BBS the short names are reversed?
The second short name is never generated on the BBS. So when I upload
the second file the same short name is generated the same as the first
file.
In the dir listing its showing -imaginary before -pixie which is what
I expect.
It asigned GALGOX~1 to -pixie because I uploaded that one first in
this particular test case.
GALGOX~2 is never assigned on the BBS. So I'm not sure I'm actually
able to
answer your question.
When you list the files on theBBS, it shows the short names and the long names. Are they reversed?
It doesn't apear so, this is the first file that is uploaded and I see it
assigned GALGOX~1.XM
GALGOX~1.XM A 23.7K galgox-pixieplanet.xm
Are there any other pertinant details that could be useful for trying to figure this out?
And... on the BBS the short names are reversed?
The second short name is never generated on the BBS. So when I
upload the second file the same short name is generated the same as
the first file.
In the dir listing its showing -imaginary before -pixie which is
what I expect.
It asigned GALGOX~1 to -pixie because I uploaded that one first in
this particular test case.
GALGOX~2 is never assigned on the BBS. So I'm not sure I'm actually
able to
answer your question.
When you list the files on theBBS, it shows the short names and
the long names. Are they reversed?
It doesn't apear so, this is the first file that is uploaded and I see
it is assigned GALGOX~1.XM
GALGOX~1.XM A 23.7K galgox-pixieplanet.xm
Are there any other pertinant details that could be useful for trying
to figure this out?
I guess I'm really sure what you're trying to figure out. Windows decides the short filename, not Synchronet. Synchronet should get/store the same file name that you see when you run "dir /x" on the file. If you replace the file *after* you add it to the filebase, that could change the short filename which would cause a mismatch. Did you do that?
get/storeI guess I'm really sure what you're trying to figure out. Windows decides the short filename, not Synchronet. Synchronet should
the same file name that you see when you run "dir /x" on the file. If you replace the file *after* you add it to the filebase, that could change the short filename which would cause a mismatch. Did you do that?
Re: Trouble uploading two files with the same first 8.3 chars. AllVers
By: Digital Man to Electrosys on Sun Mar 03 2019 09:32 pm
get/storeAnd... on the BBS the short names are reversed?
The second short name is never generated on the BBS. So when I
upload the second file the same short name is generated the same as >>> the first file.
In the dir listing its showing -imaginary before -pixie which is
what I expect.
It asigned GALGOX~1 to -pixie because I uploaded that one first in >>> this particular test case.
GALGOX~2 is never assigned on the BBS. So I'm not sure I'm actually >>> able to
answer your question.
When you list the files on theBBS, it shows the short names and
the long names. Are they reversed?
It doesn't apear so, this is the first file that is uploaded and I see
it is assigned GALGOX~1.XM
GALGOX~1.XM A 23.7K galgox-pixieplanet.xm
Are there any other pertinant details that could be useful for trying
to figure this out?
I guess I'm really sure what you're trying to figure out. Windows decides the short filename, not Synchronet. Synchronet should
thatthe same file name that you see when you run "dir /x" on the file. If you replace the file *after* you add it to the filebase, that could change the short filename which would cause a mismatch. Did you do that?
I have had my system going since about 2007 so its possible I have done
at some point, but it would not have been with these files. At any rate, I have tried starting freshing each time I have tested this so I wouldn'thave
changed the file name in this case.same
Even if I upload something like mytestfile1.txt and mytestfile2.txt the
short name is generated for the second file and I am unable to upload the second file using the batch upload menu.the
Do you think since I have had my system since 2007 that its possible I missed an update somewhere? Something that wasn't covered by sbup217b or
3/1/19 dev update?
Re: Trouble uploading two files with the same first 8.3 chars. AllVers
By: Electrosys to Digital Man on Mon Mar 04 2019 09:04 am
uploadI guess I'm really sure what you're trying to figure out. Windows decides the short filename, not Synchronet. Synchronet should get/store the same file name that you see when you run "dir /x" on the file. If you replace the file *after* you add it to the filebase, that could change the short filename which would cause a mismatch. Did you do that?
I'm trying to figure out why there is a bug that does not allow me to
two files that have the same first 8 characters. This bug doesn't exist on Vert, but it does exist on my bbs. I didn't change the file name after uploading it.Im
I think I may have been able to isolate the issue just a little bit more.
running the latest dev version 3/1/19 - and I have the bug. Vert does not have the bug and is running a feb/19 version. I tried over at a different bbs, outwestbbs which is running SBBS 3.17b Jan/19 and has the same bug I do, I am able to reproduce the bug on the outwebbbs (3.17b) but not on vert (3.17c Feb/19). I dont know why this has been so elusive, maybe becauseyour
not seeing the bug on your bbs at Vert. Maybe you have an update thatMyself
or OutwestBBS does not.
Hope you can help some more.
Hi Everyone,
I upgraded to sbbs3.17c (3/1/2019) and I'm still having a small bug when uploading files with the same first 8 characters. The two files are
galgox-imginary_numbers.xm
galgox-pixieplanet.xm
When I do a batch upload and upload the one file galgox-imginary_numbers.xm the short name is GALGOX~1.XM and the long name is stored as usual.
But when I upload galgox-pixieplanet.xm, GALGOX~1.XM becomes the short name for that file as well and then the BBS complains that the file already exists.
When I uploaded these files on vert.synchro.net I didn't have this problems as two different short names were generated for each of the files.
What am I missing in the upgrade? Or is there some maintenance program that I need to run?3.16c.
Also note that I had this same problem before my upgrade when running
Any insights would be appriciated.
Re: Trouble uploading two files with the same first 8.3 chars. AllVersname
By: Electrosys to All on Fri Mar 01 2019 04:10 pm
Hi Everyone,
I upgraded to sbbs3.17c (3/1/2019) and I'm still having a small bug
when uploading files with the same first 8 characters. The two files
are
galgox-imginary_numbers.xm
galgox-pixieplanet.xm
When I do a batch upload and upload the one file
galgox-imginary_numbers.xm the short name is GALGOX~1.XM and the long
name is stored as usual.
But when I upload galgox-pixieplanet.xm, GALGOX~1.XM becomes the short
name
for that file as well and then the BBS complains that the file already
exists.
I think I know what the problem is: you're using blind-upload rather than actually telling the BBS what filename(s) you'll be uploading (?). When you do this, the files are received into your configured temp diretory (for that node) and short-filenames are generated (by Windows) based on what other files are in that directory. If there are no other similar files in the directory (and the temp directory is normally empty), then Windows will give the file the ~1 short name. If there's a conflict, then it'll increment that short filename to ~2, ~3, etc. until there is no
conflict.and
After Windows assigns the short name and Synchronet picks it up, it then searches the other file directories to see if that file already exists
in your case, it does. So it drops the file.problems > as two different short names were generated for each of the
When I uploaded these files on vert.synchro.net I didn't have this
Probably because I'm not using Windows for my file store (I use a Samba share instead) and the shortnames are generated a little differently in that case (Samba doesn't use the same algorithm, so there are fewer conflicts).program that > I need to run?
What am I missing in the upgrade? Or is there some maintenance
Also note that I had this same problem before my upgrade when running
3.16c.
No, the version of Synchronet is not a factor in this.
Any insights would be appriciated.
When in a *future* version of Synchronet (likely 3.18), it stores full/long filenames in the filebases, this won't be an issue. For the current scheme, I can't think of a quick/easy solution for you. Maybe upload via FTP instead?
digital man
(?).I think I know what the problem is: you're using blind-upload rather than actually telling the BBS what filename(s) you'll be uploading
Windows)When you do this, the files are received into your configured temp diretory (for that node) and short-filenames are generated (by
hackbased on what other files are in that directory. If there are no other similar files in the directory (and the temp directory is normally empty), then Windows will give the file the ~1 short name. If there's conflict, then it'll increment that short filename to ~2, ~3, etc. until there is no name conflict.
This is sweet! It sounds like I finally got it across. Now I understand how the SBBS system gathers the short file name, so that will give me some way to work in regard to hacking around in the os. Maybe I can leave the files in the temp directory or something like that or come up with some other
like leaving behing an empty file with the same name or something. Thiswill
certainly give me a lot to work with.
If you're adding files to your *own* BBS, one would not normally expectto
use an X/Y/ZMODEM tranfer protocol, but rather to just copy the file to the local storage directory and then use the ;UPLOAD sysop command to add the file(s) to the database. http://wiki.synchro.net/faq:files#adding_files
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 89:25:39 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,442 |