[SOLVED, ugly] python и samba/cifs

..вдруг откуда ни возьмись возникла необходимость средствами питона скопировать файл в cifs. Прилежно порывшись везде, где это имело смысл, не нашел ничего, кроме каких-то едва документированных 3rd party модулей. Очень надеюсь, что я просто ступил и не нашел. задача-то куда как совсем тривиальная...

вот какая получилась функция для копирования файла (враппер для smbclient). Заполнение и валидация dict CIFS происходит в парсере конфига
логирование для наглядности оставил

import subprocess, os

SMBCLT = '/usr/bin/smbclient'
CIFS = {'enabled': False, 'share': '', 'user': '', 'password': ''}

def CIFScopy(srcfile, dstfile=''):
    if CIFS['enabled']:
        if not dstfile: dst = os.path.basename(srcfile)
        else: dst = dstfile

        logger.info('CIFS copy. \'{0}\' -> \'{1}\''.format(srcfile, os.path.join(CIFS['share'], dst)))
        arg = [SMBCLT, CIFS['share']]
        if CIFS['password']:
            arg.append(CIFS['password'])
            arg.append('-U')
            arg.append(CIFS['user'])
        else:
            arg.append('-N')
            logger.debug('no password provided')

        arg.append('-c')
        arg.append('put \"{0}\" \"{1}\"'.format(srcfile, dst))
        logger.debug('starting copy')
        p = subprocess.Popen(arg, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
        logger.info(p.communicate()[0].strip())
        if p.returncode == 0:
            logger.info('Successfully copied')
        else:
            logger.error('Error, return code ' + str(p.returncode))
    else:
        logger.debug('CIFS copy disabled')

Что значит в cifs? Шара

Что значит в cifs? Шара куда-то примонтирована. Значит файл нужно записть в эту директорию.

а где сказано, что для

а где сказано, что для чтения/записи конкретного файла нужна монтировка? вот тут, например, обходятся без монтировки

Beelzebubbie написал(а): а

Beelzebubbie написал(а):
а где сказано, что для чтения/записи конкретного файла нужна монтировка? вот тут, например, обходятся без монтировки

монтировка она такая, весьма надо сказать многоцелевой инструмент, только вот осторожнее надо - а то и голову проломить ею можно...

Так и делай этим модулем,

Так и делай этим модулем, делов-то (-:Е

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

безусловно, отыскать

безусловно, отыскать _какой-либо_ способ это сделать не проблема, я хотел узнать, может есть более простой и нативный способ. Просто как-то трудно поверить - столько всего у питона в стандартной библиотеке, а самбы нет?

А за каким дьяволом она там?

А за каким дьяволом она там? Это ж не ftp какой-нибудь, а сетевая файловая система. Поддержке файловой системы место в ядре ОС, а уж никак не в стандартной библиотеке ЯП.

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

а реализации этой поддержки

а реализации этой поддержки не место в стд библиотеке? ))

Нет

Нет

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

ответ, безусловно, ясен и

ответ, безусловно, ясен и краток, но хотелось бы пояснений - почему?

Поддержку ext2 же никто не

Поддержку ext2 же никто не требует.

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

аналогия хромает,

аналогия хромает, однако:
если у нас в системе есть поддержка extN, то мы можем библиотечными средствами осуществлять операции с файлами, расположенными на extN разделах, однако если у нас есть в ядре CIFS и в юзерспейсе samba - было бы логично иметь класс-враппер для операций с файлами, доступными через cifs. то есть аналог smbclient.
... а то приходится делать враппер уже для smbclient - уродливое решение, не так ли?

Beelzebubbie написал(а): если

Beelzebubbie написал(а):
если у нас есть в ядре CIFS и в юзерспейсе samba…

То мы можем работать с файлами на smb.

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

Beelzebubbie написал(а): то

Beelzebubbie написал(а):
то есть аналог smbclient.

Только вот smbclient`а в ядре нету. Это абсолютно "левая" приблуда. Это у вас с аналогией что-то...

а CONFIG_CIFS что тогда?

а CONFIG_CIFS что тогда?

если у нас в системе есть

если у нас в системе есть поддержка extN, то мы можем библиотечными средствами осуществлять операции с файлами, расположенными на extN разделах, 

Чаго чаго ?
это какие такие операции с файлами при помощи библиотек от extN - fwrite(), fopen(), fclouse() что ли ?
Что то мне сдается, что ты путаешь уровень ФС и уровень доступа к файлу

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

File object из stdtypes. есть

File object из stdtypes. есть там и write и open и seek. это видимо и есть обертки для системного API или как он правильно называется
плюс shutils модуль еще есть - пожалуйста любые высокоуровневые операции. Я ессно себе отдаю отчет что это не только для extN FS но и для любых FS, для которых загружены модули и для которых реализован соответствующий интерфейс (или как он правильно называется).

Будто файлами на smb нельзя

Будто файлами на smb нельзя оперировать точно так же.

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

было бы можно - не создавал

было бы можно - не создавал бы тему )

получается что есть 2 способа:
а) монтировать, производить действия, демонтировать
б) использовать свой враппер для smbclient (что я и сделал) или что-то вроде PySmbClient

если есть менее корявый способ, с удовольствием использую

По пункту «а» работают все

По пункту «а» работают все остальные файловые системы. Чем CIFS лучше?

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

теоретически Вы правы (в

теоретически Вы правы (в плане поддержка FS -> монтирование -> работа стд методами) - с точки зрения _реализации_... т.е. (extN, fat, ntfs, cifs)

хотя практически (в аспекте данного топика) важнее разница между _локальными_ и _сетевыми_ ресурсами вне зависимости от техники их реализации. Я имею в виду, что локальные ресурсы (ФС) имеют как правило статическую конфигурацию (fstab и прочее). Я конечно, не могу судить, но ситуация "чтобы скопировать файл на локальное хранилище - авторизуемся, монтируем хранилище, копируем, демонтируем)" выглядит нереальной. На практике просто указывается путь к файлу (предполагается что все уже [авто]смонтировано), не так ли? (Я не рассматриваю экзотические ситуации)

Другое дело для сетевых ресурсов - там вовсе не предполагается постоянное подключение, следовательно схема другая - подключение/авторизация, копирование, отключение. Одинаково что для CIFS, что для HTTP что для FTP что для прочих способов. Причем возможны ситуации, что само понятие "монтирование" будет неприменимо в принципе (например доступен только конкретный URI, указывающий на файл, но не его контейнер)

Я имею в виду что монтирование как концепция способа управления локальным хранилищем данных совершенно очевидно не подходит для организации _произвольного_ доступа к сетевым ресурсам. Мы же сайты или почтовые сервера не монтируем?

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".