Hidden/System files loses attributes during burning

[betaqlity]

FIRST

 

Heh, my first post to ImgBurn forum. I just started to use this marvellous software when version 2.0.0.0 was promoted. Unfortunately I also discovered a bug.

 

I had few files with hidden/system attributes, but when I created ISO image with "[X] Include Hidden Files" and "[X] Include System Files" options selected -ofcourse, it did add those files into image I created, but after burning that into CD, those files were not hidden anymore, but visible.

 

If the file is hidden at the first place, there is always reason for that, so it really should burn those as hidden as well, don't you think.

 

And that's my first post , ok?

[LIGHTNING UK!]

This never really occurred to me in the initial v2.0 release.

 

Since then, someone else already pointed it out and so I've already made the next one (v2.1) maintain the hidden attribute.

[fordman]

This never really occurred to me in the initial v2.0 release.

 

Since then, someone else already pointed it out and so I've already made the next one (v2.1) maintain the hidden attribute.

 

LIGHTNING UK!, you added the retention of the hidden attribute in response to betaqlity's (and a previous) post. His point was also valid for system file attribute retention also, i.e. if one were doing a direct backup of an operating system folder. It would be equally important to retain the system attribute on the recorded media.

 

Would you consider expanding the retention to the system attribute on the next release?

 

Thanks,

Ford Man

[LIGHTNING UK!]

I couldn't see such an attribute in the filesystem specs.

[fordman]

I couldn't see such an attribute in the filesystem specs.

 

OK. I think you mean that in ISO9660 specs for recordable media, there is no way to store the system attribute, but there is for the hidden attribute?

 

Thanks,

Ford Man

[LIGHTNING UK!]

Yup.

 

Obviously you have to remember that you're not backing up the attributes... they're not stored in the file or anything. It has to be something that's also available in the filesystem you then use on the optical media.

 

From what I could find, the ISO9660 filesystem only allows for a very basic set of attributes - and by 'very basic' I mean 1 attribute - the 'hidden' one!

 

I guess 'system' just wasn't really considered for ISO9660 as it's an optical disc and not your hdd where you'd run the OS from.

 

It could be different for UDF if you add structures for extended file attributes, I've really can't remember and reading filesystem specs isn't my idea of a good time

[brit0n]

Obviously you have to remember that you're not backing up the attributes... they're not stored in the file or anything.

...

From what I could find, the ISO9660 filesystem only allows for a very basic set of attributes - and by 'very basic' I mean 1 attribute - the 'hidden' one!

Or anything? What about Extended Attribute Record in the File Section? But then you have to HAVE a File Section and you have to maintain compatibility across the entire filesystem which is probably why hardly anyone does it unless they are paid a lot to do it!

 

Or am I barking up the wrong tree-hugger?

 

The PRIMARY attribute under ISO9660 is whether the "file" (directory entry) is a directory or not (if it is NOT then it is a FILE - I know some might read this and laugh their arses off, but I am sure YOU know what I am saying without expanding lol).

 

On the same logic, surely "Hidden" would be the same as saying that the file "exists for the user" meaning the Existence Bit has a value of 1 in the Extended Attribute Record? This isn't my field, but I can't think what else the following would mean:

 

Existence Bit:

 

If set to ZERO, shall mean that the existence of the file shall be made known to the user upon an inquiry by the user.

 

If set to ONE, shall mean that the existence of the file need not be made known to the user.

 

 

Hope this helps. Don't bother to give a lengthy explanation if I am wrong - just say "Nope, you are wrong"

[LIGHTNING UK!]

Yes, 'not stored in the file or anything' (don't take it out of context!) - I was simply saying that the actual user data of the file doesn't contain the file attributes, that's down to the filesystem - be it FAT, FAT32, NTFS etc.

 

Reading every byte of the file and then writing that to a new file does not mean that new file will have the same attributes.

 

 

 

The 'hidden' attribute is already supported, that's not really the issue here.

 

It's the 'bit' for a 'system' attribute that I couldn't locate.

[brit0n]

Not sure but I thought the idea of the Standard specifying an Extended Attribute Record was that any filesystem could then specify attributes according to its taste by defining them and then allocating them in the file section. How the heck you do that if there is no standard, I don't know - it would mean that a disk burned with one burning program might become a nonsense on another UNLESS each burning program then reads the definitions and changes them into its own type. Not exactly a "standard Standard" but then it was supposed to be a one-size-fits-all kind of thing.

 

Anyway, if I find the method they intended, I'll post here as you may have saved me a lot of time by so swiftly getting ImgBurn to the top of the test scores in my other tests lol

[fordman]

Yup.

 

Obviously you have to remember that you're not backing up the attributes... they're not stored in the file or anything. It has to be something that's also available in the filesystem you then use on the optical media.

 

From what I could find, the ISO9660 filesystem only allows for a very basic set of attributes - and by 'very basic' I mean 1 attribute - the 'hidden' one!

 

I guess 'system' just wasn't really considered for ISO9660 as it's an optical disc and not your hdd where you'd run the OS from.

 

It could be different for UDF if you add structures for extended file attributes, I've really can't remember and reading filesystem specs isn't my idea of a good time

 

Thanks for the confirmation - I agree that parsing UDF file system specs is not the best use of your time. I'd only be interested in such a function on a few occasions, and for those, I suppose I could just back into a .ZIP or .RAR archive and maintain all attributes, and then burn the archive. Of course that would't provide direct access to the files, but good enought in most cases if there is sufficent temporary space on the hard drive.