On Sunday 29 July 2012, Ullrich von Bassewitz wrote: > On Sat, Jul 28, 2012 at 03:10:14PM +0200, Groepaz wrote: > > > Sorry for not remembering your remark there. You seem to look for > > > feedback regarding this design decision. I'd propose to not skip it. > > > > does it show the disk label on a *nix system? i see no sense in getting > > it to be honest - usually you only want to see the files. > > The disk label doesn't show up on unix systems, because it's not part of > the directory. On CBM disks, it is. sure? i remember seeing it in DOS for example. what makes it part of the directory anyway? :) isnt it "whats returned by the directory read function" ? =P > It's similar with deleted files: For the CBMs the directory entries might > still be present, so readdir returns them. On a Unix system, deleted > entries are actually that, so they won't show up. ? that pretty much depends (only) on the filesystem in use, doesnt it? in FAT you can still see deleted files at least :) > If you want to do anything with the entries returned by readdir besides > just displaying them, you will have to pass them through a filter that > uses the _DE_ISXXX macros. And if you do that, there's no harm done when > returning the disk label. > > So I will probably change the code and return the disk label. I cannot see > anything harmful when returning it, and some programs may benefit. yeah you are right.... i am just wondering. i have used ISDIR a lot, but never had to filter a volume name. (but then again, maybe that code of mine just breaks spectacular on DOS - cant say i do care =D) -- http://www.hitmen-console.org http://magicdisk.untergrund.net http://www.pokefinder.org http://ftp.pokefinder.org Trotzdem bin ich sehr dafr, dass moeglichst viele Parlamentarier nach Afghanistan fahren. <Peter Struck, SPD> ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sun Jul 29 15:35:51 2012
This archive was generated by hypermail 2.1.8 : 2012-07-29 15:35:54 CEST