The little snip I put above was demonstrative instead of representative; in the process of trying to come up with a more accurate but concise version of the code I've seen it start to work. Clearly (and unsurprisingly) this is caused by something in my code. I'll keep banging on it and when I figure it out I'll let you know what it was.
Meanwhile, answers to questions: On Sat, Nov 5, 2016 at 6:15 PM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: I am on 10.11 and almost git head. I cannot repeat your experiment. Is the following accurate? % cat /tmp/foo.txt hello world good bye % racket Welcome to Racket v6.7.0.3. > (define p "/tmp/foo.txt") > (file-exists? p) #t > (delete-file p) > (file-exists? p) #f Yep. It's when I run ./lib/test.rkt that it fails. test.rkt does a (require "db/files.rkt") which has the code in question. On Sat, Nov 5, 2016 at 6:46 PM, 'John Clements' via Racket Users < racket-users@googlegroups.com> wrote: Four things occur to me: 1) you say that it works in command-line Racket, but you don’t say where it doesn’t work. Is it in the DrR interactions window? As part of a module? Does it work if you put it in a module (that is, a file starting with #lang) and run it from the command-line? 2) The “-f” in your system command makes me curious. Why should the -f be necessary? In this case, yes. I have 'rm' aliased to 'rm -i' (ask before deleting) so that it always checks with me before the delete. -f overrides that. 3) delete-file is documented to raise an exception if it doesn’t succeed. I’m assuming this isn’t happening? Correct. No exception is being thrown. Side note: I'm glad you said that, because I had been reading the docs as 'throws if the file does not exist', not 'throws if the deletion fails for any reason'. A quick test shows that it is the latter. I'll make a note to submit a pull request on that doc change. Current version: "Deletes the file with path path if it exists, otherwise the exn:fail:filesystem <https://docs.racket-lang.org/reference/exns.html#%28def._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._exn%7E3afail%7E3afilesystem%29%29> exception is raised." Suggested wording: "Deletes the file with path path. If the deletion fails for any reason (permissions, file does not exist, etc), the exn:fail:filesystem is raised." Second aside: it would be nice if delete-file could simply return a true/false value instead of throwing an exception. (when (not (delete-file p) ...) is much clearer and more concise than (with-handlers ((exn:fail:filesystem ...)) (delete-file p)). The 'fail fast, fail hard' philosophy seems to be a general trend with Racket; it's a legitimate strategy, but sometimes it would be nice if things could be a little gentler. I'm imagining something like a parameter that converts exception-raising behavior to #f-returning behavior. I recognize it would be a lot of work, though. 4) In principle, it’s possible that some other process is creating the file again between your call to delete-file and the call to file-exists?. Seems unlikely, yes. Good thought but nope. I created these files manually and nothing else knows about them. John On Sun, Nov 6, 2016 at 7:52 AM, George Neuner <gneun...@comcast.net> wrote: > On Sat, 5 Nov 2016 18:05:02 -0400, David Storrs > <david.sto...@gmail.com> wrote: > > >I've got this little snip of code: > > > > > >(define p "/tmp/foo/bar-28") > >(file-exists? p) ; #t > >(delete-file p) > >(file-exists? p) ; still #t ?? > > > > > >I've verified that: > > > >*) It's not throwing an exception > >*) The code is running as me > >*) The /tmp directory is 777 [I'm on OSX 10.11] > >*) The file itself is 666, although that shouldn't matter > >*) The file is owned by me > > What about the "foo" directory? > > Yep, that too. > >*) p is a string > >*) p points to the correct file > >*) There are no leading or trailing whitespace characters > >*) If I run this code from inside a command-line Racket REPL, it works > fine > >and the file is deleted > >*) If I replace (delete-file) with (system @~a{rm -f @p}) it works fine > > Do you need to use -f(orce)? > Yep. See above. > > >I thought maybe there was something weird about the /tmp directory, so I > >tried putting the target in a different directory > >(/Users/dstorrs/tmp/foo/bar-28) but that made no difference. > > I don't use OSX, but I have encountered various permission related > issues using the /tmp directory on some Linuxes: group affiliations > not being honored, objects created by one sudo user not accessible by > a different sudo user, etc. Wierd stuff. > Yeah, ditto. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
