pBurn 4.3.19

Audio editors, music players, video players, burning software, etc.
Message
Author
Henry
Posts: 863
Joined: Sun 30 Jul 2006, 02:28
Location: Oregon USA
Contact:

#181 Post by Henry »

Thanks, Sigmund,

I edited the 4 lines as suggested. It did not make a significant difference. That is, the first time after a reboot, with no theme, opening Pburn still takes about a minute, thereafter about 4 sec.

With the theme enabled, it's quite fast, so I will just "tolerate" the theme :-) It's not important.

BTW very nice how the verify function works now.

Henry

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#182 Post by mikeb »

Hi zigbert

I've been looking at a way of easily ordering tracks for audio CD's
This is what I've come up with so far...

When audio CD is selected :-
Added tracks are indexed and added to the end of the list thus preserving order.
Tracks can be moved up and down.
Removing tracks preserves the order of the remainder.
For convenience when switching to 'audio' any files already added are indexed.
The indexing method matches the system used when importing a playlist.

The attachement is a hacked down version of pburn I use for trying out ideas but the system of indexing should integrate with the latest version if deemed suitable.
Changes are in 'func' with additional buttons in 'pburn'.

mike
Attachments
audio_indexing_demo.tar.gz
(41.07 KiB) Downloaded 944 times

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#183 Post by zigbert »

Hi Mike
Thanks for your input. It will be in the next 1.4.0.
I reorganized it a bit. Your function 'index_list' is now called from 'build_burn_list'. Like this we don't need any changes in
'-add_selection'
'-add_all'
'-burnlist_remove'
Also no extra trouble integrating it with the search engine.

The annoying thing is that after moved song up/down, variable $BURNLIST is empty, and I have to select song again to move futher.

Here's the /usr/local/pburn/pburn and /usr/local/pburn/func
Attachments
pburn_audio_index.tar.gz
(13.83 KiB) Downloaded 939 times

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#184 Post by mikeb »

Hi Zigbert
I reorganized it a bit. Your function 'index_list' is now called from 'build_burn_list'. Like this we don't need any changes in
'-add_selection'
'-add_all'
'-burnlist_remove'
Also no extra trouble integrating it with the search engine.
This is why 2 heads are often better than one :) good thinking...cheers for posting the changes I look forward to having a look. Glad you liked the idea.
The annoying thing is that after moved song up/down, variable $BURNLIST is empty, and I have to select song again to move futher.
Yes i know...I am a bit hazy on how to solve that one or is it a gtkdialog limitation?

In the demo I sent you I modded the temporary directory function to call gtkdialog fileselect directly so simplifying box_chooser...which in itself I added a box to input a filename for saving..might be handy.
Also added ability to open from a .pbn file (eg with rox mime type) though this would need refining to integrate with other opening options.

Another idea which occured to me was to be able to distinguish between an audio and data .pbn file so the appropriate mode would be selected when opening.
I was thinking in terms of including a file called '.data' in the pburn folder which is removed for audio compilations....would be insignificant for a data burn and not present to cause a problem for audio if you see what I mean.

Ok off to play with the greatest and smallest burning utility in thee world :)

regards

mike

ps I missed the 'add_all' ahhhhhhhhhhhhhh

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#185 Post by zigbert »

In the demo I sent you I modded the temporary directory function to call gtkdialog fileselect directly so simplifying box_chooser...which in itself I added a box to input a filename for saving..might be handy.
This is correct, and the logic way to do it, as long as you don't have language support. Also <button cancel></button> shows a prebuild button, but it can't view label 'Avslutt', - as we cancel in Norway.
Also added ability to open from a .pbn file (eg with rox mime type) though this would need refining to integrate with other opening options.
In 1.3.0 you can open Pburn with a *.pbn file with 'pburn /path/file.pbn'
Another idea which occured to me was to be able to distinguish between an audio and data .pbn file so the appropriate mode would be selected when opening.
I was thinking in terms of including a file called '.data' in the pburn folder which is removed for audio compilations....would be insignificant for a data burn and not present to cause a problem for audio if you see what I mean.
A .data file will be visible in the burnlist , and must be removed while *.pbn opens. Still I personally feel that the 'import playlist' is most logical way to handle this. I use Picker for this purpose. BUT indeed, I'm not the negative guy. Enhanced *.pbn detection - ok with me.
Ok off to play with the greatest and smallest burning utility in thee world Smile
It is hard to disagree about the point: 'smallest' :)

Sigmund

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#186 Post by mikeb »

Hi Sigmund
This is correct, and the logic way to do it, as long as you don't have language support. Also <button cancel></button> shows a prebuild button, but it can't view label 'Avslutt', - as we cancel in Norway.
I understand..or at least I do in english :D .How about the enter filename in save box?
In 1.3.0 you can open Pburn with a *.pbn file with 'pburn /path/file.pbn'
You are definately light years ahead :)
A .data file will be visible in the burnlist , and must be removed while *.pbn opens.
Been playing with this.
I added '| grep -v .data' in build_burn_list for that but the main problem is that if a file is opened after pburn is launched there seems to be no way to update the radio buttons...would mean an alternative mode selection method...buttons and info box.
Apart from that perhaps a better way would be to use the filename eg
compilation_aud.pbn / compilation_dat.pbn....or *.pba / *.pbd nero style.

By the way well done for interpreting my posts...even I have to read them twice :D

regards

Mike

ps Is it me or is the forum struggling at the moment?

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#187 Post by zigbert »

I have another solution:

Code: Select all

# tar --label=PBURN-AUDIO -cf beep.tar /root/beep*
#
#
# tar -tvf beep.tar
V--------- 0/0               0 2008-03-21 18:25:11 PBURN-AUDIO--Volume Header--
-rw-r--r-- root/root      1188 2008-03-21 12:04:41 root/beep_01.wav
-rw-r--r-- root/root      8114 2008-03-21 11:10:41 root/beep-01.wav
-rw-r--r-- root/root      5170 2008-03-21 11:10:45 root/beep-02.wav
This will add a volume header to the tar file.

Sigmund

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#188 Post by mikeb »

I have another solution:
should read
I have another fiendishly clever solution
I'll shall leave that in your more than capable hands

mike

xekarfwtos
Posts: 7
Joined: Tue 19 Feb 2008, 08:57

#189 Post by xekarfwtos »

Hi, I think there is a minor bug in pburn. When I close pburn using the "Χ" (window top right), and then run ps, pburn is still in the running processes.
If I close it through File->Quit, the pburn process is terminated correctly.

I run pburn 1.3.0 but the problem may exist in older versions too.

Excuse me for my english

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#190 Post by zigbert »

xekarfwtos wrote:When I close pburn using the "Χ" (window top right), and then run ps, pburn is still in the running processes.
If I close it through File->Quit, the pburn process is terminated correctly.
This is not a Pburn bug, but a annoying bug in gtkdialog. It only occur to gtkdialog-scripts that has a menu.

Sigmund

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#191 Post by BarryK »

Testing Pburn 1.3.0. Running Puppy 3.01, with 'pfix=ram'

0.
Installed gtklogfileview and pfilesearch.

1.
Left-click on my directory '/puppy-devx/', then click on 'Add selection' button. Pburn displays 'Busy, please wait...". So I wait a short time, then replaced with a new message 'A data disk contains files .... '. But, 'Minimum disc size:' box DOES NOT CHANGE from zero.
I have to left click on the next directory before it updates. This is the third time I have reported this bug in this forum.

2.
I then left-clicked on my '/puppy-unleashed/' directory, then immediately 'Minimum disc size:' updated, to 371MB (the previous size).

3.
Then I click 'Add selection' again the 'Busy, please wait...', after that has gone, once again 'Minimum disc size:' does not update.

4.
So, I left-click on another directory in the left pane, and this causes 'Minimum disc size:' to update, but to 677Mb, which is too small.

5.
I look in /tmp/pburn, and see that puppy-unleashed is incomplete. All that it has are directories 'boot', 'isolinux-builds', 'kernels', 'packages'. There should be more directories immediately under 'puppy-unleashed' and a couple of dozen files.

6.
I decided to quit Pburn, hit 'Quit' button. Weird, /tmp/pburn still exists, and the contents of /tmp/pburn has only been partially deleted. What remains is /tmp/pburn/puppy-devx, with some subdirectories still in it.

7.
I manually deleted all of /tmp/pburn.

7.
I restarted Pburn, this time selected File -> Preferences -> Burn and chose 'On the fly' and disabled Joliet.

8.
Then I again went ahead and chose my '/puppy-devx/' and '/puppy-unleashed/'. Still the same problem, none of the files immediately underneath these top-level directories are in /tmp/pburn, and some sub-directories are missing. The problem is it seems to be stopping part-way through, even though there is plenty of room in /tmp (there is no tmpfs mounted on /tmp and my laptop has 1GB RAM).

9.
At this point I decided to go to my latest Dingo build...

Running Dingo pre-beta, Pburn 1.3.0
Not running in RAM, booted off a USB Flash drive and have a pup_save, which I already know highlights another weird bug in Pburn...

10.
First thing I did was choose 'File -> Preferences...' but nothing happened. Gtkdialog has a syntax error.

11.
I installed the Pburn default theme package. Now 'File -> Preferences...' came up. So, this version of Pburn mus have a theme installed, even though there is a default gtkrc in the original package.

12.
Again I chose 'On the fly' and disabled Joliet.

13.
Again, selected '/puppy-devx/' and '/puppy-unleashed/'. Okay, 371Mb for the first, after adding the second directory and clicking another directory to force the disk size box to update, this time I get 3329Mb -- wow, what a difference! But, I look in /tmp/pburn, again heaps of files and directories missing.

14.
Anyway, I decide to go ahead and do a burn. I click the 'Burn' button, then 'Burn' again and up comes the gtklogfileview window. Lots of error messages, quite alarming! Mostly about files not being readable and ignoring them.
Here is a quick copy/paste from part of the log window:

genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/rox_filer-2.6.1-pup4/ROX-Filer.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/sgmixer-0.3/sgmixer.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/usbview-1.0-patched_gtk2/usbview.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/cgtkcalc-2.1.9/cgtkcalc.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/gmeasures-0.7/gmeasures.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/zfind-0.1.0/zfind.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/0rootfs_skeleton-4.00/dev/core is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/0rootfs_skeleton-4.00/usr/include/X11 is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/0rootfs_skeleton-4.00/usr/share/ghostscript/6.50 is not readable - ignoring

...the above are all symlinks. They are symlinks that point to nothing in their current locations and only point to a valid file after installation. It is WRONG that Pburn is rejecting them.

15.
Hmmm, the log window seems to have frozen. CPU is very busy. It hasn't got to the point of burning anything yet. I'm really worried, as I'm backing up my working puppy-unleashed directory and Pburn is very unpredictable.

16.
Yeah, the log window has frozen. I hit "Emergency stop'. 'ps' shows 'mkisofs' is still running, for some reason I can't kill it. CPU still very busy. I have decided to reboot.

17.
Okay rebooted. I have anxiously examined my working puppy-unleashed directory, hoping it hasn't been compromised. Seems alright. God, I hope so. This time I decide to burn another directory, let's see, 'puppy-unleashed217' can be the guinea pig.

18.
'/puppy-unleashed217/' ...er, it doesn't appear in the right pane. At this point, I have decided to wipe the pup_save file and reboot the USB flash, with Pburn 1.2.2 installed, as that works better -- it has major bugs, but did at least burn something to the DVD.

-----------
19.
Okay, have booted from USB Flash, no pup_save so running in RAM. This buld of Puppy has gtklogfileviewer-0.1, pburn-1.2.2 and pfilesearch-1.1.

20.
I go through same steps as above, choosing /puppy-unleashed21/ ..oh, once again, although I clicked 'Add selecion' it didn't appear in right pane. Ah! Maybe the contents is too big for a DVD! ...so why didn't Pburn tell me?

21.
I quit Pburn, again had to manually delete stuff in /tmp/pburn, in case that causes any trouble next time.

22.
Restarted Pburn. This time I chose /puppy-unleashed-3xxx/ which I know is small enough to fit. I have waited three minutes, CPU very busy, Pburn seems to have hung. Determining the size requirement doesn't take that long. I had launched Pburn from a terminal, and I see lots of error messages about whiteout files -- it seems that the puppy-unleashed-3xx directory accidentally has some whiteout files in it, which has caused Pburn to hang. Why? Pburn should just archive whatever is there, as is. The core reason for this problem and earlier symlinks problem is the method chosen to create a hierarchy of symlinks in /tmp/pburn. Anyway, have decided to reboot.

23.
This time I chose another directory, puppy-unleasghed301. Same problem, does not appear in right side. This time, looking at the terminal from which I launched Pburn, I see it is reporting "no space left on device". Huh? I'm running in RAM and have heaps of space. I have to edit this file in Leafpad, Geany is corrupted.

24.
Rebooted. Did a 'du -m puppy-unleashed301' and it is 1810MB. I give up

25.
This morning I was using v1.2.2 and I did burn to DVD, but I checked the DVD and noticed some files missing, and some files that were completely wrong, which is what started me off on this. Hmm, on that occasion I had a pup_save and 'devx' loaded, so I wonder if something essential was added that enabled it to get as far as burning?
But anyway, there was something I noticed, that is really bad:

I have just now mounted that DVD, and looking at /mnt/hdb/puppy-unleashed/packages/0rootfs_skeleton-4.00/usr/etc, what I see is gtk/etc-gtk.xpm. What SHOULD BE THERE is etc/gtk where the gtk is a symlink to /etc/gtk. Earlier on I had been debugging petget, fixing a bug that win2000 reported, and I had modified /usr/etc/gtk from a symlink to an actual directory /usr/etc/gtk with a file in it, etc-gtk.xpm -- but, this experimenting is in the absolute path /usr/etc, not in the /mnt/hda3/puppy-development/puppy-unleashed (and hence packages/0rootfs_skeleton-4.00/usr/etc that I had chosen to burn to DVD. Pburn had followed the symlink /mnt/hda3/puppy-development/puppy-unleashed/packages/0rootfs_skeleton-4.00/usr/etc/gtk and burnt the absolute path /usr/etc/gtk/etc-gtk.xpm to the DVD.

CONCLUSIONS
Missing directories, missing files, symlinks totally stuffed up. There are also other issues as reported above,. TkDVD on the other hand, works flawlessly. I have tested TkDVD on all the puppy-unleashed directories. Perhaps it would be useful to examine the code in TkDVD and do it the same way.
[url]https://bkhome.org/news/[/url]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#192 Post by BarryK »

If using 'diff' to verify burnt files, it would be best I think to use the '-q' option. See reference:
http://www.gnu.org/software/diffutils/m ... /diff.html
[url]https://bkhome.org/news/[/url]

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#193 Post by mikeb »

<action>refresh:ISOSIZE</action>
is missing from the 'add selection' button..seems to solve the size update problem...right click to add was ok.
If using 'diff' to verify burnt files, it would be best I think to use the '-q' option. See reference:
Have you noticed this contradictory statement?
Differing binary files are considered to cause trouble because the resulting diff output does not capture all the differences. This trouble causes diff to exit with status 2. However, this trouble cannot occur with the --a or --text option, or with the -q or --brief option, as these options both cause diff to treat binary files like text files.
wasn't sure what to make of that but
If diff thinks that either of the two files it is comparing is binary (a non-text file), it normally treats that pair of files much as if the summary output format had been selected (see Brief), and reports only that the binary files are different. This is because line by line comparisons are usually not meaningful for binary files.

diff determines whether a file is text or binary by checking the first few bytes in the file; the exact number of bytes is system dependent, but it is typically several thousand. If every byte in that part of the file is non-null, diff considers the file to be text; otherwise it considers the file to be binary.
seems to be saying that diff will select the right mode anyway....confused...I was...though simply verifying that 2 binary files are identical is valid.

I tried various options...cmp , md5sum, cksum and all gave roughly the same performance. There doesn't seem to be anything else in the linux world to perform this function...all roads lead to diff.!....the bottleneck seems to be in reading data regardless of the method used. Only suggestion may be a notice mentioning verifying a dvd will take a long time.

Can't really comment on the missing subdirectories/files and symlink problem though there does seem to be something amiss....don't remember seeing that in early versions as I vaguely remember trying it.

mike

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#194 Post by zigbert »

Barry

This was an outstanding report :)
Even with my bad English knowledge, I felt I understood your point. As I earlier have told you, I have my reasons for keeping the symlink tree. BUT, I think I see a rather easy solution. 'readlink' reads only 1 level of a symlink, so the symlink in /tmp/pburn/ will point to the original symlink, and not its file.

There is no time for this right now. I need 48 hours to check this out, and maybe bring up a new version with -graft-points or another solution.

Sigmund

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#195 Post by BarryK »

zigbert,
I don't know, perhaps the current system can be fixed.

I did some more testing. I was puzzled why Pburn hung on some of my puppy-unleashed directories, and on some managed to get as far as burning to DVD.
I found that my puppy-unleashed3.01 and puppy-unleashed3.xx directories have some whiteout files in the xfce_BASE package, for example:
packages/xfce_BASE-4.3.99.2/usr/share/pixmaps/exo-0.3/.wh.__dir_opaque

/tmp/pburn is inside the Unionfs (except for Puppy 3.01 with a pup_save on the internal hard drive, which has a tmpfs mounted on /tmp) and creating symlinks to whiteout files is causing something chaotic to happen.

Ideally, Pburn should archive puppy-unleashed3.xx as-is, but for the current situation in Pburn, you could simply check for any files starting with '.wh.' and ignore those.

That doesn't solve other problems with symlinks though.
[url]https://bkhome.org/news/[/url]

User avatar
ravensrest
Posts: 365
Joined: Fri 22 Feb 2008, 16:43
Location: Grants Pass, Oregon

Pburn 1.3 and others

#196 Post by ravensrest »

I have used Pburn 0.6, 1.0, 1.2.2 and 1.3 with Dingo 394. They all burn and erase well. However, the log box that appears to show progress, for instance, when blanking a disk in 0.6 or 1.0 is absent when using 1.2.2 or 1.3. Is this intentional? Also, the drop-down menu to select the burn function does not disappear until after the function is completed in the later versions.
BS

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#197 Post by zigbert »

ravensrest
You're missing the new logviewer - Gtklogfileviewer. See requirements in the main post.

Mike
<action>refresh:ISOSIZE</action> is added to button 'add selection'.

Regarding verifying, we could make a question dialog --> This may take long time if burn contains many files. Do you want to continue?

Barry
I have now a working Pburn using graft-points. It still uses the symlink directory in /tmp/pburn. So it now burns symlinks as symlinks and still gives the user freedom to edit burning input (files and directories). But what I don't know: will this fix the trouble with the whiteout files?

But now the size calculation does not work, and there will be trouble if there are too many files in the burnlist. This will give mkisofs error - 'argument list too long'......I need some more time.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#198 Post by mikeb »

Hi zigbert

Something like that but maybe just as a warning in the 'finished' dialog..there's plenty of room.

On the subject of missing files when I tried the same directory later that day everything was present :shock: .

I gather adding directories from within unionfs is a bit hit and miss whereas outside of this is ok. a fair statement?

oh no I just went crosseyed again :D

mike

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#199 Post by zigbert »

Mike told us the other day that 2 heads thinks better than 1. I guess we need several heads right now.

The situation for DATA burning is:
Pburn strength is the way user can edit input files/directories before burning. You can add a new directory, remove a not wanted file inside a directory you want to burn, and you can give the file on CD/DVD another name than the original file.
Pburn weakness is that symlinks always will point to its source file. The problem occurs when adding an entire directory with symlinks. You may then get more datas than you expected (such as /root/). Also Barry has trouble with this combined with whiteout files (which I don't know a sh** about).

Some refers to TkDVD which is a great app, but it also has its weakness. In a compare you could say that TkDVDs strength is Pburns weakness, and the other way around. While TkDVD burns a chosen filelist as graft-points, Pburn builds a temporary directory which contains symlinks to the actual file, and burns this directory as is with the mkisofs parameter -f (follow symlink).

I have now started an approach to see if it is possible to combine the 2 ways of burning. My idea is to use 'readlink'. This tells us the original source of every symlink in the temporary directory (default in /tmp/pburn/). Now we can build graft-points like 'symlink=`readlink symlink`' . Since 'readlink' only read 1 level of linking, it will point to a symlink in the original directory. The problem will now occur when Barry uses Pburn as backup for a huge amount of files. - mkisofs command will be very complex (many graft-points), and we get the error: 'Argument list too long'. Mkisofs fails and cdrecord has nothing to burn. Now you maybe think. Why not just burn the list in Pburn the same way that TkDVD do. It is certainly possible, but then we will loose all edits (remove, rename, new dir) which is not in the main directory (the list shown).

So I wonder. Did it came any clever ideas while reading this.
- is there a way to split up graft-points. Adding 100 every turn...
- is there another way of adding datas to an iso. mounting *.iso in rox is readonly, so I guess it is not THAT easy.
- other...

I have a 'working' proto if you want to dive along.

Edit: Some load thinking. We keep the temporary directory as it is now. In addition, we split all inputs (adds and edits) into 3 categories.
ADDS: If user add file or directory (add selection, add all), choosen file/directory are written to list 'ADDS'. Here are directories NOT listed recursively, so it will only apply ONE graft-point.
EDITS: If user rename an item in the burnlist this file/directory are written to the list 'EDITS'. This file will get its unique graft-point. All items added to a 'new directory' also needs a unique graft-point. But this is only in the first level of the new directory. It means that if user adds a directory inside this 'new directory' we needs only 1 graft-point for the added directory.
EXCLUDERS: If user remove or rename item it will be written to list 'EXCLUDERS'. This must be checked against original file/dir in case user renames an already renamed file. List with excluded items fits with mkisofs parameter -exclude-list.

Edit 2: This is simpler:
ADDS: If user add file or directory (add selection, add all), choosen file/directory are written to list 'ADDS'. Here directories are NOT listed recursively, so it will only apply ONE graft-point.
If user rename an item in the burnlist this file/directory are also written to the ADDS list. Format of ADDS list is equal the graft-points format: "path/name_on_CD"="/path/original_name". Since ADDS list contains complete information about where it should be placed in iso-filesystem, 'new directory' does not need to be handled else, and renaming doesn't need its own EDITS-list.
EXCLUDERS: If user remove or rename item it will be written to list 'EXCLUDERS'. List with excluded items fits with mkisofs parameter -exclude-list. EXCLUDERS-list must be checked against original file/dir in case user renames an already renamed file.

Edit 3:
My last theory will fail because 'remove' an item in the root-directory on CD/DVD shouldn't be added to EXCLUDERS list. It should only be removed from ADDS list. Pburn needs to know the main directories, and then check against them. A main directory will be the root directory and any 'new directory' made of user in the burnlist. If user renames an item in a main directory it should only be renamed in ADDS list, not added to EXCLUDERS list.

When 'Save' a *.pbn file, Pburn saves all links in /tmp/pburn. To keep graft-points and -exlude-list it also needs to save the files containing ADDS, EXCLUDERS and main directoies.

Sigmund

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#200 Post by zigbert »

I have been fiddling with graftpoints, and begins to see where the road is leading us. Including graftpoints affects many functions, but users will only get one checkbox more - Follow symlink. when TRUE, Pburn uses the original burning mode. When FALSE, Pburn will use graftpoints. Default will be FALSE.

There are many functions that are touched by graft-points, and therefor the next release will NOT be stable. When I have managed the graft-point burning mode, I will upload the code. Then it will remain:
- Calculating size when 'follow symlink' is TRUE. I haven't looked at it, and I don't have a solution. This could be tricky...
- Some new Help-text
- Bugfixing - YOU are important.
- Maybe a documentation that explains the underlying structure of the Pburn code.

The graft-point todo-list looks right now like this: (+ is finished)
+ add selection browser
+ add selection search
+ add all browser
+ add all search
- add list (import)
- import iso
+ remove
+ rename
+ make dir
- save *.pbn
- open *.pbn
- size calculation
+ build_command
+ clean_up

Post Reply