Go Back   Club CDFreaks - Knowledge is Power > International Chat: Software related > Nero SDK Discussion Forum


Commercial message



Nero SDK Discussion Forum Discuss, NeroCmd.exe File Naming bug?/feature? at International Chat: Software related forum; I'm writing a "snapshot" backup program which will allow me to write a CD-R in a couple of clicks which will take a snapshot of my day's or hour's work. It involves some subtle analysis of the folder trees involved to save certain subfolders from a


Reply
 
Thread Tools
Old 01-12-2004   #1 (permalink)
New on Forum
 
Join Date: Nov 2004
Posts: 6
NeroCmd.exe File Naming bug?/feature?

I'm writing a "snapshot" backup program which will allow me to write a CD-R in a couple of clicks which will take a snapshot of my day's or hour's work. It involves some subtle analysis of the folder trees involved to save certain subfolders from a much larger tree, and not all the rest of the tree, so my backup can be quick. It can't just use the last-modified date, because what I want is the whole folder if any file in the folder has been modified recently. This is not difficult logic, just not the way Windows thinks of files and folders.

The problem I'm having with NeroCmd is the way the file list gets specified, and what it does with them on the disk it is writing.

The first "glitch" is in the documentation. I can't find anywhere where it says that a can be a folder name, but it certainly can be. What is actually does is controlled by the "--recursive" option. If the "--recursive" option is not set, "c:\windows" would create an empty folder on the target disk. I would have hoped that it would create the folder and add all of the files in it, and that the "--recursive" would only control whether or not subfolders to that folder would be included. One problem with "--recursive" is that you can't turn it on or off as the file list is processed.

One "glitch?/feature?" is that a "filename" specified in the input file always seems to get placed in the root directory of the output disk. Similarly, a folder, no matter how deeply located in the input list, will be placed as a folder off the root directory in the output disk. I can live with this(barely), but there is an awful lot of flexibility lost in placing files on the output disk. It could be that the program logic in NeroCmd would be too tricky or the input options too complex, but it seems to me that there should be some simple way around this.

One possible solution would be if NeroCmd had an option of something like "--keep_directory_structure", so that "C:\a\b\c.txt" would be placed as "x:\a\b\c.txt" on the CD-R. This would require NeroCmd to create folders as needed on the output disk, but it shouldn't be too complex.

I'm hoping I'm just missing some obvious program option, but I just don't see it.

Thanks

Howard Richoux
hnrsoftware is offline   Reply With Quote
Old 02-12-2004   #2 (permalink)
Nero Developer
 
Join Date: Oct 2003
Posts: 605
Quote:
The first "glitch" is in the documentation. I can't find anywhere where it says that a can be a folder name, but it certainly can be. What is actually does is controlled by the "--recursive" option. If the "--recursive" option is not set, "c:\windows" would create an empty folder on the target disk. I would have hoped that it would create the folder and add all of the files in it, and that the "--recursive" would only control whether or not subfolders to that folder would be included. One problem with "--recursive" is that you can't turn it on or off as the file list is processed.
Indeed, this is kind of reverse logic but this is the way it woks now. Writing a folder dir will put an empty folder in the disc root. Writing a dir\* will put all files contained in the dir in the disc root. Using --recursive in both cases will copy the whole directory structure.

Quote:
One "glitch?/feature?" is that a "filename" specified in the input file always seems to get placed in the root directory of the output disk. Similarly, a folder, no matter how deeply located in the input list, will be placed as a folder off the root directory in the output disk. I can live with this(barely), but there is an awful lot of flexibility lost in placing files on the output disk. It could be that the program logic in NeroCmd would be too tricky or the input options too complex, but it seems to me that there should be some simple way around this.
This is not a glitch. This is by design. The only place a folder can be put on a destination disc is in the disc's root, unless specified otherwise. Currently, there is no way to specify it otherwise. NeroCMD being a command line utility, receives all its input by the command line string. It may seem intuitive to allow the features and richness of a drag and drop GUI utility here but doing so would require a lot more complexity in the command line syntax, as you noted yourself. I am not saying it is impossible, just that is currently unsupported. Therefore, everything specified on the command line is put straight into the disc root.

As NeroCMD source code is available in the NeroSDK, one can alter it to one's personal needs. Future releases might contain additional features to rectify some of the issues mentioned here.
alexp is offline   Reply With Quote
Old 02-12-2004   #3 (permalink)
CD Freaks Member
 
Join Date: Dec 2003
Location: uk
Posts: 234
Re: NeroCmd.exe File Naming bug?/feature?

I think it is worth adding that the thread starter mentioned in another thread that he was also interested in NeroCom and that the functionality he requires is available in NeroCom if he wishes to pursue that further.

Mike
unison is offline   Reply With Quote
Old 03-12-2004   #4 (permalink)
New on Forum
 
Join Date: Nov 2004
Posts: 6
Re: NeroCmd.exe File Naming bug?/feature?

Thanks - as I indicated in my other thread, there are some reasons, possibly not good ones, for me to start with NeroCmd.exe rather than NeroCom.

The NeroCmd User's Manual is a very useful reference, but it errs on the side of brevity in discussing the "big picture", such as even one good paragraph on the "{disk file 1} {disk file 2}> ..." (hmmm... angle brackets in a forum post just disappear) and "--recursive" meaning and interaction. Most of the other "--xxx" options are self-explanatory, or at least have keywords I can track down elsewhere - like "iso" "joliet" "udf" ...

I'm not expecting a tutorial on all aspects of CD/DVD reading and writing, but things specific to the NeroCmd implementation should be documented there. It is a personal failing of mine, but I can't "read" C++ at all. I can read VB like my high-school Spanish, but C dialects just don't look right to me - sorry. After 35 years of FORTRAN, COBOL, BAL, SNOBOL, APL, TAL, and a similar number of operating systems, my brain has just channelized to PASCAL-type languages (DELPHI is great) and nothing else "looks" right.

I guess my basic question is - is "{disk file 1} {disk file 2} ..." and "--recursive" everything there is for file selection specifications in NeroCmd?, or did I miss something?

Unless I'm missing something, "--recursive" is not a very useful command option. I think I've determined that specifying "c:\windows" without "--recursive" will just create an empty folder on the output disk. (Is that ever a useful function?) It would seem more reasonable to me to have "--recursive" be the default and I'm not sure if there would ever be a need for a "--norecursive" as a command option. If you specify a folder as an input file, you would get all recursive contents and that would be that.

To me, the useful implementation of "--recursive" would be that if you do not specify "--recursive" and a specify a folder as a filename, you would get just a folder plus that one level of files, and if you do specify "--recursive", you get that folder of files plus all subfolders and files. The implication of that implementation would be to also be able to turn recursive off and on as needed. I have not experimented to see if options and files can be mixed syntactically, or whether all options have to be specified first, followed by the file list. If they can be mixed, then it should be pretty easy to implement a "--norecursive" option to turn it back off again.

BTW - none of my "complaints" about NeroCmd should be construed as insulting. I've worked with many programs before, and I find NeroCmd to be quite solid and relatively forgiving given the large number of things it is trying to do. I'm merely trying to figure out how to make it work for my purposes and what its limitations actually are.

Thanks - Howard Richoux
hnrsoftware is offline   Reply With Quote
 
Reply

Bookmarks

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On
Trackbacks are Off
Pingbacks are Off
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
nerocmd.exe monkeydaz Nero SDK Discussion Forum 0 07-11-2005 23:03
nerocmd.exe medienentwickler Nero SDK Discussion Forum 1 15-08-2005 22:52
Bug in NeroCMD ? Creosote Nero SDK Discussion Forum 3 23-03-2005 10:15
how to write using nerocmd.exe yihing Nero SDK Discussion Forum 2 10-02-2004 17:38
Burning a file to DVD+RW with NEROCMD.EXE quacka Nero SDK Discussion Forum 0 09-02-2004 01:17


All times are GMT +2. The time now is 09:50.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.1.0