Re: [Ql-Users] Hard directories
- Original Message - From: Tony Firshman t...@firshman.co.uk To: ql-users ql-us...@q-v-d.com Sent: Sunday, November 28, 2010 3:44 PM Subject: [Ql-Users] Hard directories Is there any automated way to copy files *and* hard directories without manually using MAKE_DIR? Presumably WCOPY will only copy the files and not the directories. Can MAKE_DIR be used after copying? I am restoring my BBS from backup. Tony I'm assuming that the backups are not compressed or packed together into an archive of some form...that is, they are a straight copy of the original BBS files as they were on your hard disk. If so, try my The Copier program. If the backups are in the same sub-directory names as they came from, it might be able to do what you want. If it doesn't quite do what you want I can send you the sources to tweak it for yourself if you want (although I T-H-I-N-K the source BASIC is already in there). http://www.dilwyn.me.uk/files/copier.zip On the same page, there's an Adrian Ives package (called dirtools???) which might also be of help. I also have a simple program I think was published in QL Today for doing this in a very basic way, which might be eaier to rewrite. Let me know if you'd liek a copy of that too, I don't think it's on my website unless it's in one the ARTICLES pages, or possibly in the HD Utils package on the same page as the Copier. http://www.dilwyn.me.uk/files/hdutils.zip Dilwyn Jones -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 t...@firshman.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1170 / Virus Database: 426/3285 - Release Date: 11/28/10 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
-Original Message- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users- boun...@lists.q-v-d.com] On Behalf Of Tobias Fröschle Sent: 28 November 2010 17:47 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Hard directories Am 28.11.2010 16:44, schrieb Tony Firshman: Is there any automated way to copy files *and* hard directories without manually using MAKE_DIR? Presumably WCOPY will only copy the files and not the directories. Can MAKE_DIR be used after copying? I am restoring my BBS from backup. Tony Tony, no, not out of the box. TK2's WCOPY was built long before the advent of real directories. If I remember right, there's a directory tree copy routine coming with SMSQ/E source codes, and I guess Dilwyn's site has quite a number of tools that do the same thing. Cheers, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm The 'cp' copy command that comes with c68 can copy everything including hard directories. I used to sue it regularily to copy a complete hard disk partition contents to another one including the directory structure. Dave Walker Tel: +44 (0)1707 652791 Mob: +44 (0)7999 218953 Web: http://www.itimpi.com Skype: itimpi ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
The 'cp' copy command that comes with c68 can copy everything including hard directories. I used to sue it regularily Why did you sue it? Did it go disastrously wrong or something? :o))) Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
If you use WinBack to create a backup, there was a (useful) utility which took a snapshot of the directory structure, built a new SuperBasic file (called Make_directory_bas I think) and you would run this first against a new disk prior to a restore. It made life easier as the restore would put the files back into the correct location, as opposed to having all the files live in the top level directory and then make_dir everything afterwards. That way of doing it resulted in huge piles of holes in the directory structure and doing DIR WIN1_ would result in quite a substantial delay as the DIR code skipped over all the holes. Of course, if you didn't use WinBack's utility to build the tree, then you are slightly stuffed I'm afraid. :-( Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
A very good solution. I wonder if this new device could work on a directory path with shortened directory names to maintain more backward computability. For example if one was at root (win1_) and created a new directory called 'ThisisaVeryLongDirectoryName' then the new system device path would be 'win1/ThisisaVeryLongDirectoryName/' but the legacy directory path could be something like 'win1_This01_'. This would be something along the lines that Microsoft took when moving from DOS, only their problem was filename length not path length. All the old directory commands would work on the abbreviated path and a new set of traps and directory navigation commands could be designed to use the new long path such CD and LS. Cheer Malcolm P Witte wrote: On the problem of compatibilty with old programs, a workaround is to use some scheme like DEV (or DOS for that matter): You set the dev root to some real directory DEV_SET 1, win72/dir1/dir2/..dirn/ then Load (in Quill or whatever) dev1_mydoc.doc BTW that method, given the appropriate underlying mechanisms, would permit a radical revision of the file and directory system without braking too many programs. File manager-type programs would be hit. What a pity that wrappers of the file system are so basic! It makes it so awkward to upgrade. Getting directory information should have been done via procedure calls rather than reading those rigid data structures directly. Any new file system (miracles mat happen!) should get that right (even if it expects to be the last!) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
Marcel Kilgus wrote: Norman Dunbar wrote: Ok, to be really honest, I can think of one reason - someone will have to write it as part of SMSQ. Yes, that and that basically ALL applications would have to be updated to make use of the new facilities. Difficult to pull off. One more reason was the cry for staying QDOS compatible, which limits pretty much what one can do. ... and even QDOS compatible is hard. One has to be at least three characters under the maximum. I discovered this when using the network to access files on my HD, wihich increased the size by three and knocked out a lot of 'paths' on my BBS. I had to reduce a lot of Phil Borman's default directory names. The UNIX 'hard' directory names were around when Tony T was developing QDOS. What a pity he did not mimic that right from the start. Tony ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
Ralf Reköndt wrote: Hmm, why have all apps to know, where they are? They don't need to know where they are, but most apps I use work with files, be it source-code, spread-sheets, word-processor documents, you name it. If the system let them believe, they are in their root (if necessary), they should run. Simply look at the TK3 sources, I'v sent to you years ago. There is a mechanism for that: Yes, that is a concept known as chroot in Unix circles. There it is often used for security purposes. But in our context, what use is a (e.g.) text editor that can only edit files in its own directory? Having long path names is not a self-serving goal, it is only useful if applications can actually access all those deep files. Imagine not being able to use QPAC2 anymore because the directory you want to navigate to is too deeply nested in the tree. Cheers, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
Of course, the 36 character limit is always there, even in the TK3 way. All was done mostly for those programs which have/had hard coded file destinations in there program or data files. For that, it was the best solution (even Professional Publisher is such dirty in some of its files). Nevertheless, it *is* a way...;-) Cheers...Ralf - Original Message - From: Marcel Kilgus Ralf Reköndt wrote: If I want load (e.g. in an editor) a file from another directory, I simply use e.g. flp1_\anotherdir_source_asm. Maybe not the most elegant way, but it works. Then you have again a 36 character limit, have you not? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
Marcel Kilgus wrote: Imagine not being able to use QPAC2 anymore because the directory you want to navigate to is too deeply nested in the tree. That was what I had in mind when I suggested that we also change the directory separator. So if the path is full of '/' (for example) then those are the new style file system and are handled by new code and if there are no '/' but '_' then that uses the old style file system. Ok, I know the whole thing is probably moot, but hey, we can call it brainstorming and have a bit of fun can't we? With the 'dual' filesystem in place, old programs carry on with their device_directory_file_extension and new programs, written to take advantage, use the new style device/directory/file.extension. The problem you allude to above is when you have old style programs on a system with mixed or new style file systems, then they will not cope with the new style at all - and QPAC2's Files utility will, to all intents and purposes, be useless. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
Good day, Norman, well, I was a bit annoyed, because I have sent Tony the sources (just to open his ideas), explained, why it should be better to use a different system esp. for WIN files, but there was no comment. Perheps he has finished the WIN driver for the Miraculix hard disk and do not wanted to change a thing, who knows? And it was long before he has written the QPAC suite. Fact is, nowadays, esp. the handling on WIN is not the thing, which is ideal. Hmm, we all were prepared to take the WMAN2 extensions (and we DO) , and it is a bit useless (IMHO) to implement all of the old QL WMAN stuff just to be compatible. One can see it from both sides. I just see it (in this thing) on the WIN side. And for that I just ask, how much it would take, to give us a better way. Yes, brainstorming. SMSQ ist quite *very* good, but there are ways to make it even better ;-). Cheers...Ralf - Original Message - From: Norman Dunbar Marcel Kilgus wrote: Imagine not being able to use QPAC2 anymore because the directory you want to navigate to is too deeply nested in the tree. That was what I had in mind when I suggested that we also change the directory separator. So if the path is full of '/' (for example) then those are the new style file system and are handled by new code and if there are no '/' but '_' then that uses the old style file system. Ok, I know the whole thing is probably moot, but hey, we can call it brainstorming and have a bit of fun can't we? With the 'dual' filesystem in place, old programs carry on with their device_directory_file_extension and new programs, written to take advantage, use the new style device/directory/file.extension. The problem you allude to above is when you have old style programs on a system with mixed or new style file systems, then they will not cope with the new style at all - and QPAC2's Files utility will, to all intents and purposes, be useless. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Hard directories
Evening Ralf, In the meantime, we are not QL-compatible in some cases, there are programs, which just run under WMAN2, and that is ok. So why can't we have real subdirectories for the harddisk side? A QXL file isn't interchangable. To be honest, I can't find a reason myself why we are still limited to 36 characters after the device name. Obviously, the directory entry holding a 36 byte space for the file name is partly to blame as the directory name is duplicated within the directory entry. Ok, to be really honest, I can think of one reason - someone will have to write it as part of SMSQ. On the harddisk side, the way of the subdirectories could be better. Maybe, all was designed for compatibility, understandable for disks but not for harddisks. I would like to see something similar to the Linux/Unix manner of operating where the directory name is separate from the file name and thus, we could easily (I use the term, loosely - I have no idea how easy it would be) have just the filename as the 36 byte entry and the previous paths within the full (possibly longer than 36 character name) typed in filename would each be removed as the directory structure was 'walked'. For example: win1_sources_c68_MyProject_MySubProject_MySubSubProject_main_c is a long file name. On a hard disk/QXL file, the root of the Win1_ drive's directory would have the details of a 'file' named 'sources' and it would have the file_type of directory. Within that directory on disc, the 'c68' entry would also indicate a directory. It would not be stored as 'sources_c68' but simply as 'c68' and so on down the path. At the bottom of the path, when we eventually get there, the 'main_c' entry would have the file type of data file and we are done. Ok, a small problem raers it's ugly head - how to tell that main_c is a single file and not a further directory 'main' with a file called 'c' in it? Maybe we need a new file separator (equally, directory separator) like we have to differentiate between the directory names and the file extensions. I still think the extension part of the name of the file (or folder) should count in the number of characters allowed - so 'main.c' is 6 characters' I would love to see the directory system changed to allow either underscores as at present - for backward compatibility, plus, accept a Linux/Unix style '/' as a directory separator. So, using that option, I could open the above file using: win1/sources/c68/MyProject/MySubProject/MySubSubProject/main.c I can but dream. The advantage of not having the parent directory name encoded as part of the file name itself is obvious, we get a much deeper path in the file system and still have a maximum of 36 characters for the terminal filename. Does anyone know the way, how the Rebel way or the Thor way was? Were that real subdirectories or just the same as FS2? I'm not 100% sure, but I think the Thor was the first to offer sub-directories as we currently know them. They had a different file type to normal data files - but for the life of me, I can't remember what they were. The file_type of -1 (255) we have at present for directories was not the one used on the Thor. Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
