I’ve since abandoned this approach.
* Did you see my previous question? It looked like your logic would result in
directories xxx-APPL, xxx-APPL-APPL, xxx-APPL-APPL-APPL, etc. -- or was I
mistaken? If there is code elsewhere that is resetting shootPath to not have
the APPL suffix, could
On Apr 18, 2011, at 1:56 AM, Andy Lee wrote:
But seriously...
Oops. I had inserted a lame joke, but deleted it. Unfortunately I forgot to
delete the But seriously
--Andy
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not
On Apr 18, 2011, at 12:56 AM, Andy Lee wrote:
* What if you don't use NSFileManager to rename the directory, but
rename([shootPath UTF8String], [newShootPath UTF8String])?
Minor quibble: Use -fileSystemRepresentation to get C strings for BSD/POSIX
APIs working with file paths.
Cheers,
Ken
On Apr 15, 2011, at 1:47 AM, Scott Anguish wrote:
if (foundRange.location 0) { // should be comparing to
NSNotFound, but that failed miserably.
newShootPath=[shootPath stringByAppendingString:@“-APPL”];
// make sure I’ve not already done this
I tried to reproduce your problem by creating directories ~/wtf/FromHere and
~/wtf/ToHere, with three files in FromHere named 1, 2, and 3. I switch over to
using ToHere-NEW when it detects a file whose name is = 2.
My test code renamed the directory and switched over to it just fine:
-
not sure what to say, my code wasn’t doing that.
I ended up churning through all the files once, finding the .mp4s, getting the
whereas information and then making the directory I needed first.
I just didn’t have more time to spend trying to figure it out.
Now I feel like I need to though...
But seriously... there's more going on in your code than in mine, so the
problem must lie in whatever is different (or be somehow caused by the data
rather than the code). Like you say, what you're doing *seems* pretty
straightforward and what you're seeing *seems* impossible (my favorite kind
On Apr 15, 2011, at 12:47 AM, Scott Anguish wrote:
I have an app that sorts a bunch of files and sticks them in a newly made
directories. When it finds a file that identifies WhereFroms (via spotlight,
from a downloaded file) I want it to rename that directory and then copy the
rest of the
On Apr 15, 2011, at 2:05 AM, Ken Thomases wrote:
On Apr 15, 2011, at 12:47 AM, Scott Anguish wrote:
I have an app that sorts a bunch of files and sticks them in a newly made
directories. When it finds a file that identifies WhereFroms (via spotlight,
from a downloaded file) I want it to
On Apr 14, 2011, at 23:51, Scott Anguish wrote:
[snip!]
—
The app works without the renaming of the directory, and I want feedback in
the table as to what got moved and where. and since I need to use spotlight
and don’t want to learn the necessary extras, how to access spotlight and
such
On Apr 15, 2011, at 1:51 AM, Scott Anguish wrote:
The directory is named a name derived from the file
so /tmp/boo/Friday
and when it encounters a file that has more specific information, it should
be renamed
/tmp/boo/Friday-APPL
that should rename the existing directory with the
Adding to what I said earlier...
On Apr 15, 2011, at 1:51 AM, Scott Anguish wrote:
It’s the messed up behavior of moveItemAtPath:toPath:error: that is weirding
me out.
But this seems like wrong move behavior which I should be diagnosing and then
reporting.
If you suspect a bug in
Am 15.04.2011 um 08:51 schrieb Scott Anguish:
It always creates a new directory wit the new name, in the existing
shootPath directory (for example /tmp/boo/Friday) with Friday-APPL
instead. and then copies the newly found files into that.
If I get you right, the *real* path for the new
Scott, are you copying the files asynchronously? I wonder if there are some
files still in the process of being copied to the old directory, so the old
directory either doesn't really go away, or it gets recreated. What happens if
you comment out the actual copying of the files? And if you log
Have you tried this scenario outside of /tmp and verified that the owner of the
application running matches the owner of the directory? I'm wondering if
there's some interplay with a semi-sandboxing I've read happens with files in
/tmp. I've found that when I have issues with NSFileManager, I
On Fri, 15 Apr 2011 01:47:56 -0400, Scott Anguish said:
if ([[eachPath pathExtension] isEqualToString:@mp4]) {
Not what you were asking, but you should probably do a case insensitive
test here, there are a lot of FAT16 USB keys out there that turn
extensions into .MP4. :) Also, better to test
it actually isn’t in /tmp, that was just an example. it’s done in my home
directory.
On Apr 15, 2011, at 10:57 AM, Gary L. Wade wrote:
Have you tried this scenario outside of /tmp and verified that the owner of
the application running matches the owner of the directory? I'm wondering if
nothing special, the files get copied in order. it’s a really simple app.
The goal is to rename the existing directory with the new -APPL extension and
then copy new files into that.
On Apr 15, 2011, at 9:36 AM, Andy Lee wrote:
Scott, are you copying the files asynchronously? I wonder if
Yes, if it was a situation where that was an issue, I would. But it’s a
personal situation, only .mp4s are going to show up.
On Apr 15, 2011, at 2:55 PM, Sean McBride wrote:
On Fri, 15 Apr 2011 01:47:56 -0400, Scott Anguish said:
if ([[eachPath pathExtension] isEqualToString:@mp4]) {
OK, before anyone asks... I’m working on a tool for my own use, and so I don’t
want to bug people at work about it.
Thus, I bug you. :-)
I’m perplexed by this one.
I’m trying something stupidly simple, and I’m getting really odd results.
I have an app that sorts a bunch of files and sticks
20 matches
Mail list logo
