Jump to content

ImgBurn Support Forum uses cookies. Read the Privacy Policy for more info. To remove this message, please click the button to the right:    I accept the use of cookies

Photo

Hidden/System files loses attributes during burning



  • Please log in to reply
9 replies to this topic

#1 betaqlity

betaqlity

    ISF Newbie

  • Members
  • Pip
  • 5 posts

Posted 12 August 2006 - 03:25 PM

FIRST :w00t:

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? :blush:

#2 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 27,315 posts
  • Gender:Male
  • Location:United Kingdom

Posted 12 August 2006 - 03:30 PM

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.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#3 fordman

fordman

    ISF Member

  • Members
  • PipPip
  • 184 posts

Posted 01 April 2007 - 05:59 PM

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

#4 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 27,315 posts
  • Gender:Male
  • Location:United Kingdom

Posted 01 April 2007 - 09:47 PM

I couldn't see such an attribute in the filesystem specs.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#5 fordman

fordman

    ISF Member

  • Members
  • PipPip
  • 184 posts

Posted 01 April 2007 - 10:29 PM

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

#6 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 27,315 posts
  • Gender:Male
  • Location:United Kingdom

Posted 02 April 2007 - 12:07 AM

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 ;)
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#7 brit0n

brit0n

    ISF Newbie

  • Members
  • Pip
  • 39 posts

Posted 02 April 2007 - 03:02 PM

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" ;)

"If a thing's worth doing, it's worth spending time finding free software to do it
- which someone else thought was worth spending time writing.
If you fail to find it, write it yourself!"


#8 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 27,315 posts
  • Gender:Male
  • Location:United Kingdom

Posted 02 April 2007 - 03:16 PM

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.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#9 brit0n

brit0n

    ISF Newbie

  • Members
  • Pip
  • 39 posts

Posted 02 April 2007 - 06:02 PM

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

"If a thing's worth doing, it's worth spending time finding free software to do it
- which someone else thought was worth spending time writing.
If you fail to find it, write it yourself!"


#10 fordman

fordman

    ISF Member

  • Members
  • PipPip
  • 184 posts

Posted 02 April 2007 - 07:09 PM

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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users