I think you are missing the point JB. Permissions are a tricky thing. The user is accessing the folders based upon his security token created at the time he logged in. Suppose this is a file server, and midway through, the IT person changed permissions? You will get an error trying to open that folder unless the new permissions include you.
Other issues can involve another application currently accessing the file in a copy or move process. What they are saying is, instead of bailing out with an error message, pass over the problem folder. Maybe make a list and write it out to a log, then alert the user afterwards they those files/folders cannot be accessed. I’ll give you a GREAT example of how this can happen. I upgraded an OS X server which employed XSAN volumes, and in the process I had to upgrade my XSAN volumes themselves. Unbeknownst to me, but beknownst to Apple, the new XSAN volumes were cASE sENSITIVE! My backup software was NOT! So when some users decided to rename their existing files by simply correcting the case, the backup software began throwing errors because the file existed, but wasn’t the same file, because it didn’t have the same name… exactly. So the backup software had to rewrite their algorithms to either ignore case, or correct for it. The point is, when dealing with files and folders, it will behoove you to write some really robust error checking before putting your software out there. Bob S On Sep 30, 2014, at 13:32 , JB <sund...@pacifier.com> wrote: > And what do you mean by folders that cannot > be accessed? Since when are they not able > to be accessed? I access them all of the time. > I am a typical user who accesses files & folders > everyday the same way. > > So you are telling me they cannot be accessed > and I encourage you to put a program on the > market and explain that to those who access > their folders every day and your program does > not allow them to access it. > > They will read your response and quit your program > and continue to access their folders as usual and you > will not hear from them again because they do not want > to spend their time explaining to you they are able to > access their folders without your program. > > If it causes me problems it will cause someone else > problems and I am not going to explain to them do > not use those folders with my program or block it > and give them a dialog stating it cannot be accessed. > > I liked the idea of recursive but it does not work good > for me. > > John Balgenorth > > > > On Sep 30, 2014, at 1:19 PM, Richard Gaskin <ambassa...@fourthworld.com> > wrote: > >> JB wrote: >> >>> For now I will not use recursive to list files or folders. >> >> I think we've established that recursion errors are the symptom but not the >> problem (that is, unless you have directory structures deeper than 400,000 >> levels, but then I suspect you'd see inode problems long before you'd have a >> chance to walk through them with LC). >> >> The question is: How do we handle error conditions when a folder cannot be >> accessed? >> >> The original code you had bails because it isn't doing appropriate error >> checking, and Alex' modification bails whenever it encounters a folder it >> can't access. >> >> Unless you write some code to handle that differently, it's bailing either >> way. >> >> -- >> Richard Gaskin >> Fourth World Systems >> Software Design and Development for the Desktop, Mobile, and the Web >> ____________________________________________________________________ >> ambassa...@fourthworld.com http://www.FourthWorld.com >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
