Message Area
Casually read the BBS message area using an easy to use interface. Messages are categorized exactly like they are on the BBS. You may post new messages or reply to existing messages!

You are not logged in. Login here for full access privileges.

Previous Message | Next Message | Back to Synchronet Multinode BBS Softwar...  <--  <--- Return to Home Page
   Networked Database  Synchronet Multinode BBS Softwar...   [340 / 900] RSS
 From   To   Subject   Date/Time 
Message   Electrosys    Digital Man   Trouble uploading two files with the same first 8.3 chars. AllVe   March 5, 2019
 6:30 AM *  

  Re: Trouble uploading two files with the same first 8.3 chars. AllVers
  By: Digital Man to Electrosys on Mon Mar 04 2019 11:25 pm

 DM> Re: Trouble uploading two files with the same first 8.3 chars. AllVers
 DM> 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.

 DM> I think I know what the problem is: you're using blind-upload rather than
 DM> actually telling the BBS what filename(s) you'll be uploading (?). When
 DM> you do this, the files are received into your configured temp diretory
 DM> (for that node) and short-filenames are generated (by Windows) based on
 DM> what other files are in that directory. If there are no other similar
 DM> files in the directory (and the temp directory is normally empty), then
 DM> Windows will give the file the ~1 short name. If there's a conflict, then
 DM> it'll increment that short filename to ~2, ~3, etc. until there is no name
 DM> conflict. 

 DM> After Windows assigns the short name and Synchronet picks it up, it then
 DM> searches the other file directories to see if that file already exists and
 DM> in your case, it does. So it drops the file.

 > 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. 

 DM> Probably because I'm not using Windows for my file store (I use a Samba
 DM> share instead) and the shortnames are generated a little differently in
 DM> that case (Samba doesn't use the same algorithm, so there are fewer
 DM> conflicts). 

 > 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. 

 DM> No, the version of Synchronet is not a factor in this.

 > Any insights would be appriciated.

 DM> When in a *future* version of Synchronet (likely 3.18), it stores
 DM> full/long filenames in the filebases, this won't be an issue. For the
 DM> current scheme, I can't think of a quick/easy solution for you. Maybe
 DM> upload via FTP instead? 

 DM> digital man

 
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 hack like leaving
behing an empty file with the same name or something. This will certainly give
me a lot to work with.

Some of these issues get a little bigger than the free time I have for bbsing,
I think that may be part of the reason why it has taken so long for me to get
this issue across. Plus running windows sometimes especially on my budget core
2 duo in a VM can be a bit unweildy. (I'm working on making that better) Upload
via FTP isn't really a solution for me but certainly a feasable workaround.

Yes, Im using blind uploads because the files are > 8.3 chars. That is the only
way my current shell works at this time, which is fine. 

The important thing is that you understand where I'm comming from and see it as
a bug/shortcomming as I do.

Thanks for spending time on this, I feel its usefull for the filesystem, as I
have always had trouble managing my files on the board with this particular
'old school feature' :)

Thanks,
Electrosys
--- SBBSecho 3.06-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  Show ANSI Codes | Hide BBCodes | Show Color Codes | Hide Encoding | Hide HTML Tags | Show Routing
Previous Message | Next Message | Back to Synchronet Multinode BBS Softwar...  <--  <--- Return to Home Page

VADV-PHP
Execution Time: 0.0859 seconds

If you experience any problems with this website or need help, contact the webmaster.
VADV-PHP Copyright © 2002-2024 Steve Winn, Aspect Technologies. All Rights Reserved.
Virtual Advanced Copyright © 1995-1997 Roland De Graaf.
v2.0.140505

Warning: Unknown: open(c:\Sessions\sess_7umpo404k4l59g2vrm5a6jhp56, O_RDWR) failed: No such file or directory (2) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\Sessions) in Unknown on line 0 PHP Warning: session_start(): open(c:\Sessions\sess_7umpo404k4l59g2vrm5a6jhp56, O_RDWR) failed: No such file or directory (2) in D:\wc5\http\public\VADV\include\common.inc.php on line 45 PHP Warning: Unknown: open(c:\Sessions\sess_7umpo404k4l59g2vrm5a6jhp56, O_RDWR) failed: No such file or directory (2) in Unknown on line 0 PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\Sessions) in Unknown on line 0