[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnupod] Add --copy option to gnupod_search?

From: Richard van den Berg
Subject: Re: [Bug-gnupod] Add --copy option to gnupod_search?
Date: Wed, 16 Mar 2011 17:12:50 +0100

On 16 mrt. 2011, at 16:44, Stuart McLaren <address@hidden> wrote:

> Ok. What I plan to do is have it work as follows:
> 1) update gnupod_search --help --> Would include info on the --copy option
> 2) gnupod_search --copy --> Would backup whole ipod to current directory
> 3) gnupod_search --copy --directory=/tmp --> Would backup whole ipod to /tmp
> 4) gnupod_search --copy --directory=/tmp -a John_Doe -l Rock_On 
> --> Would backup artist John_Doe's Rock_On album to /tmp
> (ie the behaviour with matching would be exactly the same as delete)
> Note that output would be in the form:
> "John_Doe - Rock_On"/01_Song_One.m4a
> "John_Doe - Rock_On"/02_Song_Two.m4a
> Does that work for you?

Sounds good to me, but let's hear Henrik's opinion as well (he is the main 
gnupod coder). 

>> Interesting. Is this an iPod or OS limitation? What OS are
>> you using?
> Debian 6.0, 2.6.32-5-amd64
> Without this option there's a mismatch between the
> read ipod path for the file and the real mount point, ie
> gnupod looks for
> /mnt/ipod/f19/file.mp3
> but that doesn't exist, without the mount option its actually
> /mnt/ipod/F1/file.mp3. With the mount option they
> match up.

According to Google shortname=lower is the default for linux vfat mounts. Will 
accessing a directory u6sing F19 not work when f19 exists on vfat? Silly case 
insensitive file systems..

Please remember to copy the mailing list on replies. 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]