Hi there!
On Fri, 6 Dec 2002, Pavel Roskin wrote:
> The right solution would be to avoid mc_stat() in the "archiveless"
> filesystems.
Here is the patch. It checks the archive existence only when the extfs.ini
says that it should need it. But it sends the archive filename to the
script regardl
On Sun, 8 Dec 2002, Pavel Roskin wrote:
> However, this problem is with a buggy (or too pedantic?) program that
> cannot output the date properly even in the human readable form, let alone
> machine readable representation.
Yes, this is a problem. Do you have any good solution for this? I don't
On Sat, 7 Dec 2002, Pavel Roskin wrote:
> Hello!
>
> > The script must be able to work even with filename only unzip command
> > specification. I've just tested this and it works like a charm! This
> > assumes the unzip to be within the path.
>
> Support for zipinfo still needs to be tested.
Hi!
On Fri, 6 Dec 2002, Pavel Roskin wrote:
> Your patch derives the properties of the filesystem from the existence of
> a file with a certain name. That the wrong approach. The properties of
> an extfs filesystem are encoded in the corresponding script.
The correct way would be to ask the sc
Hi!
Here is a patch that removes the need of the ':' within the extfs.ini and
also handles the stat() failure conveniently.
regards
STan
mc.no.colon.patch.gz
Description: GNU Zip compressed data
Hi!
On Thu, 5 Dec 2002, Pavel Roskin wrote:
> Do you think that the hardcoded path was better? Or you have some other
> solution? Can you check if your solution wasn't already used in the past
> and later rejected?
Well, if there was an absolute path than it was not very good, of course.
> If
Hi!
--
CVS/ChangeLog:
* configure.in: Generate vfs/extfs/uzip.
--
I'm not sure that the uzip script should depend on the paths where the
unzip and other needed binaries are found on the build machine. Is it
intentional? Why?
best regards
STan
___
Mc
Hi!
Replying to myself here after some more code investigation
On Thu, 5 Dec 2002, Standa Opichal wrote:
> vfs_uid 0'. In any case the extfsstat is only used for explicit permission
> checks on the archive file entry. Currently these checks are out of order
> so if it all w
Hi!
On Thu, 5 Dec 2002, Pavel Roskin wrote:
> There is another solution - make drive part of the filename:
> /#dos:/a/
I don't see where can I get the /a/ part within the script. Can you help
me here with some more specific code suggestion?
> Then current_archive->extfsstat will still have ran
Hi!
On Wed, 4 Dec 2002, Pavel Roskin wrote:
> I don't understand why you need to disable this check. I don't think it's
> right to reuse the archive filename as the disk name. Actually, what I
> suggested was "/#dos:a/" - this syntax doesn't need your patch.
Yes, it does although need quite
Hi Pavel!
I've played with it...
As I've already sent... the 'in archive path' is not sent to the script
handling the particular filesystem type
I found faster to remove the archive existence check (there is no need
for it. In fact the extfs script does this also for sure if it really
ne
Hi!
On Wed, 20 Nov 2002, Pavel Roskin wrote:
> > Here is a small patch I needed to display one particular archive
> > contents without errors. If it is convenient to neglect errors like weird
> > dates then it can be usefull. Maybe even the other archive scripts should
> > have such checks? Wh
Hi!
Here is a small patch I needed to display one particular archive
contents without errors. If it is convenient to neglect errors like weird
dates then it can be usefull. Maybe even the other archive scripts should
have such checks? What do you think?
regards
STan
$ cvs -z3 diff uzip
Ind
Hi!
On Fri, 15 Nov 2002, Pavel Roskin wrote:
> I don't like this approach. It means registering a separate extfs for
> each drive. If we are going to support all letters, it will be 26 scripts
> or symlinks. It's almost like having a separate script for every zip
> file.
Yes, I don't like thi
Hi!
On Thu, 14 Nov 2002, Pavel Roskin wrote:
> > cd /#c
>
> I get a message
>
> Cannot chdir to "/#c"
> No such file or directory (2)
Yes, you need to create the link like this to let it work (I mean the C:
mtools drive filesystem entry):
su -
cd /usr/share/mc/extfs
ln -s a c
echo "c:" >>ext
Hi!
Thanks for the patch improvements. It is working perfectly here.
I would just like to report a little bug in the extfs. If I cd to e.g.
/#a and than I cd to e.g. /#d where both these extfs filesystems are of
the same type (linked in the /usr/share/mc/extfs and added to the
extfs.ini like "a:\
Hi there!
I've recently played with the mc and mtools. The extfs for mtools a needs
the patch below to run properly with the current mtools packages. With
this patch the compatibility issues do not exist.
best regards
STan
PS: In case of replies, please use my personal email as I'm not a
mem
17 matches
Mail list logo
